自己修復ファイルシステムは一般的な用途でどの程度有益でしょうか?

Question

私は最近、データの冗長性と可用性のために高度なファイルシステム (Btrfs、ZFS) を調べ、それらが提供する追加機能、特にデータ破損に対する「自己修復」機能に興味を持ちました。

しかし、一歩下がって、従来の mdadm-Raid1 + Ext4 ソリューションと比較して、一般的な家庭/SMB 使用において、この利点が欠点 (Btrfs のバグと未解決の問題、ZFS の可用性とパフォーマンスへの影響) を上回るかどうかを理解する必要があると思います。どちらの方法でも、ミラー バックアップが利用できます。

アーカイブ目的で使用され、リソースは限られているが、ECC メモリと安定した電源を備えたファイル サーバーがいくつかあると仮定します。

1. 実際にデータが破損してファイルが読み取れなくなる可能性はどのくらいありますか? どのようにですか?
2. Ext4 またはシステム ファイル マネージャーは、コピー/移動操作でデータ エラーをすでに検出し、少なくとも問題を認識できるようにできますか?
3. 1 つのドライブに不良セクタがあるために madam-Raid1 ドライブの 1 つに異なるデータが保存されている場合はどうなりますか? それでも正しいファイルを取得できますか? それともアレイがどのファイルが正しいかを判断できず、完全に失われますか?

Answer 1

はい、機能的なチェックサム付きファイルシステムは非常に良いものです。しかし、本当の動機は、神話的な「ビットロット」にはありません。する起こることは非常に稀です。むしろ、このようなファイルシステムの主な利点は、エンドツーエンドのデータチェックサムディスク自身のプライベート DRAM キャッシュの障害や電源の問題による誤動作に関連する、誤った書き込みやデータ破損などの誤ったディスク動作から積極的に保護します。

私は、Linux RAID 1アレイが電源の問題で故障したときに、この問題を直接体験しました。1つのディスクのキャッシュがデータを破損し始め、ディスクセクター自体に埋め込まれたECCは何もキャッチしませんでした。すでに腐敗していたECC は破損したデータ自体に基づいて計算されました。

異常を検出してファイルシステムを一時停止するチェックサム付きジャーナルのおかげで、XFS は被害を限定しました。ただし、一部のファイル/ディレクトリは修復不可能なほど破損しました。これは、即時のダウンタイムのプレッシャーに直面していないバックアップ マシンであったため、ZFS で再構築しました。問題が再発したとき、最初のスクラブ中に、ZFS は他のディスクから正常なコピーを読み取って、影響を受けたブロックを修正しました。結果: データ損失なし、ダウンタイムなし。これらは、チェックサム付きファイルシステムを使用する 2 つの非常に良い理由です。

データチェックサムは非常に重要なので、デバイスマッパーはそれを提供する（T-10 DIF/DIX仕様をエミュレートすることによって）ことを目標としている。dm-整合性は、この保護を従来のブロックデバイス（特にRAID1/5/6などの冗長デバイス）に拡張するために開発されました。ストラティスプロジェクト包括的な管理 CLI/API に統合される予定です。

しかし、そのようなファイルシステムによってもたらされる潜在的な利点は、それらが引き継ぐ欠点と比較されるべきであるという点にはご指摘のとおりです。ZFS の主な問題は、標準カーネルにメインライン化されていないことですが、それ以外は非常に高速で安定しています。一方、BTRFS はメインライン化されていますが、多くの重要な問題があるパフォーマンスの問題もあります (データベースや VM の場合、CoW を無効にすることが一般的に推奨されますが、これによりチェックサムが無効になりますが、率直に言って、これは受け入れられる答えではありません)。BTRFS を使用する代わりに、XF​​S を使用して最善の結果を期待するか、dm 整合性保護デバイスを使用します。

Answer 2

1. 私が使用していた Seagate HDD では、zfs scrub を実行するたびにチェックサムが失敗し始めました。数週間後に失敗しました。ZFS と Btrfs には、データとメタデータのチェックサムがあります。ext4 には、メタデータのチェックサムしかありません。

2. CRC エラーとメタデータ チェックサム エラーのみ。データ破損が発生する可能性があります。

3. 不良セクタがある場合、問題はありません。ディスク全体が「故障」しますが、他のディスクは「正常」です。問題は、データの CRC が正しいのに、データが破損している場合です。これは、大容量ディスクのため、ランダムに発生することがあります。

Answer 3

私は、Linux と FreeBSD の両方で、サーバーとホーム オフィスの NAS の両方で、6 年以上にわたって ZFS を運用してきました。ZFS は安定していて、高速で、信頼性が高く、単純なデバイスmdやext4ファイル システムでは不可能なエラーを検出して (可能な場合は) 修正するのを個人的に見てきました。

しかし、一歩下がって、この利点が欠点（Btrfs のバグと未解決の問題、ZFS の可用性とパフォーマンスへの影響）を上回るかどうかを理解する必要があると思います。

ライセンスに関しては、ZFSはオープンソースであり、CDDLライセンスの下でリリースされているだけであり、法的にLinux カーネルがリリースされている GPLv2 ライセンスと互換性があります。詳細はこちらこれは、ライセンスが「しばらく宙ぶらりん」の状態にあることを意味するものではなく、テクニカル非互換性。これは単に、メインラインのLinuxカーネルソースにモジュールが含まれておらず、次のような場所から取得する必要があることを意味します。https://zfsonlinux.org。Debianなどの一部のディストリビューションでは、ZFSがディストリビューションに含まれていることに注意してください。Debian / Ubuntu への ZFS のインストールは、通常、1 つのコマンドで実行できますapt。

パフォーマンスに関しては、十分な RAM があれば、ZFS のパフォーマンスは、メモリ、使用可能なプール スペース、データの圧縮可能性に応じて、ext4 に近いものから ext4 を超えるものまでさまざまです。私の意見では、ZFS の最大の欠点はメモリ使用量です。実稼働サーバーに 16 GiB 未満の RAM しかない場合は、ZFS は避けたほうがよいでしょう。これは非常に単純化された経験則であり、ZFS のメモリ要件についてはオンラインで多くの情報があります。私は個人的に、32GB RAM を搭載したホーム オフィスの Linux システムで 10TB プールと 800GB プール、およびいくつかのバックアップ プールを実行していますが、パフォーマンスは良好です。このサーバーまたLXC を実行し、複数のサービスが実行中です。

ZFS の機能は、データのチェックサムや自己修復機能にとどまりません。強力なスナップショットは LVM スナップショットよりもはるかに優れており、インライン lz4 圧縮によりディスク書き込みが減るため、実際にパフォーマンスが向上します。私は個人的に、10 TB プールで 1.55 倍の節約を達成しました (ディスク上のわずか 6.3 GiB のスペースに 9.76 GiB のデータを保存)

私の経験では、プールの使用率が 75% または 80% に達すると、ZFS のパフォーマンスが低下します。そのポイントを下回っている限り、一般的な家庭/SMB での使用には十分なパフォーマンスが得られるはずです。

私が見た ZFS が不良データを検出して修正したケースでは、根本的な原因は不明ですが、不良ディスク ブロックである可能性が高いです。また、ECC メモリがあり、UPS を使用しているため、RAM でデータが破損したとは考えられません。実際、ZFS チェックサムのメリットを得るには、ECC RAM が必要です。ただし、過去 6 年間で、ブロックのチェックサムが失敗したケースを数件 (~10-15 件) 見てきました。ZFSがmd RAIDよりも優れている点の1つは、ZFSがチェックサムエラーの影響を受けるファイルを認識できることです。冗長性のないバックアッププールにチェックサムエラーが発生した場合、ZFSはちょうど影響を受けたファイルを特定し、それらのファイルを置き換えることができました。

ZFSが使用するライセンスはLinuxカーネルと互換性がありませんが、モジュールのインストールは非常に簡単です（少なくともDebianでは）。ツールセットに慣れれば、管理も簡単です。インターネット上ではZFSでデータが完全に失われるのではないかと懸念する人が多いですが、私は一度もないZFS に移行してからはデータが失われていません。ZFS スナップショットとデータ チェックサム/冗長性の組み合わせにより、私は何度もデータ損失を回避できました。これは明らかに有利であり、個人的にはアレイに戻ることはありませんmd。

Answer 4

ZFS は、その起源 (2001 年に Sun Microsystems によって開発) のおかげで、非常に堅牢であるとも付け加えておきます。現在利用可能なオープン ソース バージョンは、約 10 年前に Sun Microsystems によってリリースされた最後のオープン ソース バージョンの 1 つからフォークしたもので、Oracle が Sun Microsystems を買収した後に ZFS のソースをクローズした後、オープン ソース コミュニティによってさらに開発が進められてきました。

Oracle 自身も、エンタープライズ ストレージ システムで使用されている ZFS のクローズド ソース バージョンをまだ維持しています。

ただし、ZFS は、かなり強力で、調整できる点が非常に多いため、学習に多少時間がかかります。また、私がこれまで取り組んだストレージ ファイル システムの中で、実際にメンテナンスが簡単な数少ないものの 1 つです。プールを RAID5 セットアップから RAID6 (より正確には RAID-Z1 から RAID-Z2) に移行する必要があったケースがありました。通常、このような操作では、すべてのデータをコピーし、RAID を再構成し、データをコピーして戻す必要があります。ZFS では、セカンダリ ストレージを接続し、1 つのコマンドでプールをコピーし、アレイを必要に応じて再構成し、別のコマンドでプールをコピーして戻します。

ただし、いくつか注意点があります:

1. ZFS の利点を活かすには、ZFS にディスク自体を処理させる必要があります。そのため、ドライブ コントローラは JBOD をサポートしている必要があります。そうすることで、ZFS はディスクを直接認識できるようになります。すべての RAID 構成は ZFS で処理されます。パリティ データはスクラビングやその他のタスクに使用されるため、RAID コントローラによって隠すことはできません。
2. 他の人が述べているように、ECCメモリは強く推奨するZFS では必須ではありませんが、RAM に書き込まれた内容は不変であり、破損しないことが前提となっています。そのため、ECC 非対応の RAM を搭載したシステムで実行し、メモリが故障した場合、ZFS はアレイのスクラブ中にデータを破損する可能性があります (スクラブとは、ZFS がプールからデータを読み取り、他のドライブに保存されているパリティ情報から読み取る必要のあったデータを計算し、見つかったエラーを修正することを意味します)。
3. ZFS はデータ損失の防止に非常に優れていますが、その RAID-Z1 は RAID5 と同じ問題を抱えています。つまり、ドライブの URE 率が高すぎる場合、アレイの再構築時に 1 台のディスク障害が発生すると、大容量 (1TB 以上) ドライブの大規模アレイが完全に機能しなくなる可能性があります。これは、再構築中に残りのドライブからパリティからすべてのデータを読み戻すと、ドライブのサイズが原因で数学的に回復不能な読み取りエラーがほぼ確実に発生するためです。ストレージ システムの操作に精通しておらず、何をすべきかわかっている場合は、RAID6 / RAID-Z2 を実行してください。

初心者や家庭環境の場合、一般的に FreeNAS をお勧めします。メンテナンスが非常に行き届いており、セットアップも簡単なので、初心者に最適です。