自己修復ファイルシステムは、一般的な使用にとってどの程度有益ですか？
私は最近、データの冗長性と可用性について高度なファイルシステム（Btrfs、ZFS）を調査し、それらが提供する追加機能、特にデータ破損に対する「自己修復」機能に興味を持ちました。
ただし、従来のmdadm-Raid1 +と比較して、一般的なホーム/ SMBの使用法について、この利点がデメリット（Btrfsのバグと未解決の問題、およびZFSの可用性とパフォーマンスへの影響）を上回っているかどうかを理解する必要があります。 Ext4ソリューション。ミラーリングされたバックアップはどちらの方法でも使用できます。
アーカイブの目的で使用され、リソースが限られているが、ECCメモリと安定した電源を備えたファイルサーバーが2つあるとします。
- 実際にデータが破損してファイルが読めなくなる可能性はどのくらいありますか？どうやって？
- Ext4またはシステムファイルマネージャーは、コピー/移動操作のデータエラーを既に検出して、少なくとも問題を認識できますか？
- 1つのドライブに不良セクターがあるために、madam-Raid1ドライブの1つが異なるデータを保持している場合はどうなりますか？それでも正しいファイルを取得できますか、それともアレイはどのファイルが正しいファイルであるかを判断できず、完全に失うのでしょうか？
はい、機能するチェックサムファイルシステムは非常に良いものです。しかし、本当の動機は神話的な「bitrot」には見られませんが、が発生することは非常にまれです。むしろ、主な利点は、そのようなファイルシステムがエンドツーエンドのデータチェックサムを提供し、誤った書き込みやデータとしてディスクの誤動作によってアクティブに保護されることです。電源の問題が原因で、ディスク自体のプライベートDRAMキャッシュが失敗したり、動作が不正になったりすることに関連する破損。
電源の問題が原因でLinux RAID 1アレイが故障したとき、私は直接この問題を経験しました。 1つのディスクのキャッシュがデータの破損を開始し、ディスクセクター自体に埋め込まれたECCは何もキャッチしませんでした。単に書き込まれたデータがすでに破損していて、ECCは破損したデータ自体。
奇妙なことを検出してファイルシステムを一時停止したチェックサムジャーナルのおかげで、XFSは損傷を制限しました。ただし、一部のファイル/ディレクトリは修復不可能なほど破損しています。これはすぐにダウンタイムのプレッシャーに直面しないバックアップマシンだったので、ZFSで再構築しました。問題が再発した場合、最初のスクラブ中に、ZFSは他のディスクから正常なコピーを読み取ることにより、影響を受けたブロックを修正しました。結果：データの損失やダウンタイムは発生しません。これらは、チェックサムファイルシステムを使用する2つの非常に良い理由です。
データチェックサムは非常に価値があるため、 （dm-integrity と呼ばれる）、T-10 DIF/DIX仕様をエミュレートすることによってそれを提供するデバイスマッパーターゲットが、この保護を正確に拡張するために開発されたことに注意してください古典的なブロックデバイス（特にRAID1/5/6として冗長なもの）。 Stratisプロジェクト により、包括的な管理CLI/APIに統合されます。
ただし、そのようなファイルシステムによってもたらされる潜在的な利点は、それらが継承する不利益と比較する必要があるという点があります。 ZFSの主な問題は、標準カーネルに組み込まれていないことですが、それ以外は非常に高速で安定しています。一方、BTRFSはメインライン化されていますが、 多くの重要な問題があります およびパフォーマンスの問題（データベースまたはVMの一般的な提案は、CoWを無効にすることです。これは、チェックサムを無効にすることです-率直に言って、許容できる答え）。私はBTRFSを使用するのではなく、XFSを使用して最善の結果を期待するか、dm-integrityで保護されたデバイスを使用します。
Seagate HDDを使用していて、zfs scrubを実行するたびにチェックサムが失敗し始めました。それは数週間後に失敗しました。 ZFSとBtrfsには、データとメタデータのチェックサムがあります。 ext4にはメタデータchcksumのみがあります。
CRCエラーとメタデータチェックサムエラーのみ。データ破損が発生する可能性があります。
不良セクターがある場合は問題ありません。ディスク全体が「故障」しますが、もう1つのディスクは「正常」です。問題は、データのCRCが正しいが、データが破損している場合です。これは、ディスクが大きいためにランダムに発生する可能性があります。
LinuxとFreeBSDの両方で、サーバーとホームオフィスNASの両方にZFSを本番環境で6年以上使用しています。私はそれが安定していて、高速で、信頼できることを発見しました、そして私はそれが単純なmdデバイスまたはext4ファイルシステムはできなかっただろう。
ただし、一歩下がって、この利点が欠点（Btrfsのバグと未解決の問題、およびZFSの可用性とパフォーマンスへの影響）を上回るかどうかを理解する必要があると思います。
ライセンスに関しては、ZFSはCDDLライセンスの下でリリースされたばかりのオープンソースであり、LinuxカーネルがリリースされているGPLv2ライセンスとlegally互換性がありません。 詳細はこちら 。これは、「しばらくの間、ライセンス供与状態」の状態にあることを意味するのではなく、technicalに互換性がないことも意味しません。それは単に、メインラインのLinuxカーネルソースにモジュールがなく、 https://zfsonlinux.org のような場所から取得する必要があることを意味します。 debianなどの一部のディストリビューションでは、ディストリビューションにZFSが含まれていることに注意してくださいDebian/UbuntuへのZFSのインストールは、通常、単一のaptで実行できますコマンド。
パフォーマンスに関しては、十分なRAMの場合、ZFSのパフォーマンスは、メモリ、使用可能なプールスペース、およびデータの圧縮性に応じて、ext4に近いものから優れたext4までです。ZFSの最大の欠点は、私の意見です。メモリ使用量：16未満の場合GiB of RAM for a production server）は、ZFSを回避する必要がある場合があります。これは、親指; ZFSのメモリ要件については、オンラインで多くの情報があります。私は、32GBのホームオフィスLinuxシステムでいくつかのバックアッププールと共に10TBプールと800GBプールを個人的に実行していますRAMとパフォーマンスは素晴らしいですこのサーバーalsoはLXCを実行し、複数のサービスを実行しています。
ZFSの機能は、データチェックサムと自己修復機能をはるかに超えています。強力なスナップショットはLVMスナップショットよりもはるかに優れており、インラインのlz4圧縮により、ディスクの書き込みを減らすことで実際にパフォーマンスを向上させることができます。私は個人的に10TBプールで1.55倍の節約を達成しました（9.76GiBのデータを6.3GiBのディスク領域にのみ保存します）
私の経験では、ZPFのパフォーマンスは、プールが75％または80％の使用率に達したときに満たされます。その点を下回っている限り、パフォーマンスは一般的な家庭/ SMBの使用には十分以上です。
ZFSが不良データを検出して修正するのを見た場合、根本的な原因は明確ではありませんでしたが、おそらく不良ディスクブロックでした。また、EECメモリとUPSを使用しているので、データがRAMで破損したとは思いません。実際、ZFSチェックサムからメリットを得るにはEEC RAM=が必要です。しかし、過去6年間にチェックサムに失敗したブロックの少数（〜10-15）のケースを見てきました。md RAIDに対するZFSの主な利点の1つは、ZFSがチェックサムエラーの影響を受けるファイルを認識できることです。したがって、冗長性のないバックアッププールにチェックサムがあった場合エラー、ZFSは影響を受けたexactファイルを教えてくれたので、それらのファイルを置き換えることができました。
ZFSが使用するライセンスはLinuxカーネルと比較できないにもかかわらず、モジュールのインストールは（少なくともDebianでは）非常に簡単で、ツールセットに慣れれば管理は簡単です。多くの人々がインターネット上のZFSによる完全なデータ損失の恐れを挙げていますが、私はnever ZFSへの移行後にデータを失っており、ZFSスナップショットとデータチェックサム/冗長性の組み合わせにより個人的に私を救いました複数回のデータ損失から。それは明らかな勝利であり、個人的にmd配列に戻ることは決してありません。
実際にデータが破損してファイルが読めなくなる可能性はどのくらいありますか？どうやって？
十分な時間が与えられれば、それはほぼ確実に起こります。偶然にも、それは先週私に起こりました。私のホームファイルサーバーは、いくつかの悪いRAMが定期的なロックアップを引き起こしていました。結局、マシンをリタイア（かなり古くなった））し、ドライブを別のマシンのエンクロージャーに移動することにしました。インポート後のスクラブにより、8 TBプールからチェックサムエラーのある15ブロックが見つかり、修復されました。これは、おそらくRAMおよび/またはロックアップの不良が原因でした。ディスク自体に問題はありませんでした。 SMARTの健康状態を確認し、次のスクラブでテストしました。
Ext4またはシステムファイルマネージャーは、コピー/移動操作でデータエラーを既に検出して、少なくとも問題を認識できるようにすることはできますか？
いいえ、そうではありません。一部のファイル形式にはアプリケーションレベルのチェックサムがある場合がありますが、それ以外の場合、私の場合に発生した破損の種類に注目するものはありません。
1つのドライブに不良セクターがあるために、madam-Raid1ドライブの1つが異なるデータを保持している場合はどうなりますか？それでも正しいファイルを取得できますか、それともアレイはどのファイルが正しいファイルであるかを判断できず、完全に失うのでしょうか？
1つのドライブが不良であることが確実にわかっている場合は、そのドライブをアレイから故障させて、正常なドライブからすべての読み取りを処理できます（または、より賢明な方法として、不良ドライブを交換します。これにより、正常なドライブから交換用のデータがコピーされます。 ）。しかし、書き込み時のランダムなビットフリップ（私とshodanshokに起こったようなもの）によってドライブ上のデータが異なる場合、チェックサムなしでどちらが正しいかを選択する決定的な方法はありません。
また、mdは通常、noticeを行いません。通常の操作中にミラー内の2つのドライブが同期していないことを意味します。これにより、読み取りがいずれかのディスクに直接転送され、最も高速な結果が得られます。ミラーペアの両側を読み取って不一致を報告する「チェック」機能がありますが、それを実行した場合、またはディストリビューションが定期的に実行して結果を報告するように設定されている場合のみです。
実際にデータが破損してファイルが読めなくなる可能性はどのくらいありますか？どうやって？
明らかに、無限の時間を考えると、それに遭遇することは確実です。
ただし、現実的には、非常に高価なエンタープライズグレードのハードウェアがない限り、それはかなり可能性が高く、それでもそれほど可能性は高くありません。
ただし、ファイルの内容を変更するだけでデータが読めなくなるというデータの破損に遭遇する可能性が高くなります（非常に多くの小さなファイルがない場合を除き、単純な統計では破損している可能性が高くなります）ファイルメタデータよりもファイルデータ）。これが発生すると、ハードウェアが不良である場合と同じように、あらゆる種類の奇妙な動作が発生する可能性があります（通常、ハードウェアの不良よりも一貫性があり、ローカライズされます）。運が良ければ、重要ではないデータが破損して、簡単にデータを破壊できます。適度に運が悪い場合は、システムを最初から再構築する必要があります。 本当に不運な場合は、エラーが発生し、本番システムの重要なデータに偶然アクセスしてサービスを停止しているため、破産しました。スクラッチして、データベースを本来あるべき状態に戻します。
簡単に言うと、データの破損はホームユーザーでも心配するほどの可能性があります。
Ext4またはシステムファイルマネージャーは、コピー/移動操作でデータエラーを既に検出して、少なくとも問題を認識できるようにすることはできますか？
Ext4はこの点で悪名高いです。内部整合性エラーが発生した場合のデフォルトの動作は、次の再マウント時にチェックするファイルシステムにマークを付け、何も問題がないかのように続行することです。この動作のため、過去にシステム全体を失いました。
より一般的には、ほとんどの場合、データを検証するように特別に設計されていないファイルシステムから期待できる最善の方法は、独自のデータ構造またはファイルメタデータで内部エラーが発生した場合に読み取り専用で再マウントすることです。ただし、ファイルシステムが境界チェックなどの単純なものを超えて、独自の内部構造の検証を特に処理しない限り、これはすべてをキャッチするわけではなく、奇妙な方法でうまくいかないだけです。
これ以上のものを入手するには、ファイルシステムに、チェックサム、エラー修正コード、イレイジャーコーディング、または同様のアプローチを使用して、ファイルシステム自体の内部データ構造を確認する必要があります。それでも、ファイルデータに対して同じことを行わない限り、データ損失の無視できないリスクがあります。
1つのドライブに不良セクターがあるために、madam-Raid1ドライブの1つが異なるデータを保持している場合はどうなりますか？それでも正しいファイルを取得できますか、それともアレイはどのファイルが正しいファイルであるかを判断できず、完全に失うのでしょうか？
これは、RAIDレベル、正確なRAID実装、および自動復旧に設定されているかどうかによって異なります。あなたが自動回復していると仮定します：
RAID1およびRAID10の場合：
- ハードウェアRAIDとレプリカが2つしかない場合、通常は最初のレプリカを選択し、それにアレイを同期します。
- レプリカが3つ以上ある一部のハードウェアRAIDシステムでは、レプリカの大部分が一致するかどうかを確認し、一致する場合は一致しないものを上書きします。
- ソフトウェアRAIDの場合、不一致が書き込みの失敗の結果であることが明確に示されていない限り、ハードウェアRAIDの場合と同じです（この場合、完全に書き込まれたことがわかっているコピーを選択します）。
- BTRFSでは、どのコピーが正しいチェックサムを持っているかを調べ、そうでないものを置き換えます。
- ここでは、ZFSはBTRFSのように機能すると思います。
RAID4/5/6およびその他のイレイジャーコーディングの場合、復旧に関してはほとんどすべてが同じように動作します。可能であれば残りのデバイスからデータが再構築されるか、アレイが実質的に失われます。この場合のZFSとBTRFSは、データが正しいかどうかを確認する（総I/Oに関して）より迅速な方法を提供します。
これらはいずれもファイル単位で動作せず、ほとんどが「正しい」ものを簡単に選択することができません。完全に動作するか、完全に失敗するか、または非同期領域の正常または不良データを返します。
完全にするために、私は https://bcachefs.org について言及したいと思います。これは確かにカーネルにはまだありませんが、IMHOはZFSとbtrfsに取って代わる予定です。
これは、すでにカーネルに組み込まれているbcacheに基づいており、Bツリーシステムを使用してファイルシステム機能を構築しています。
孤独な開発者は、Patreonによって後援されてフルタイムで作業し、信頼性に重点を置いています。
現時点で気弱な人のためではありませんが、このコメントが古くなるにつれて、bcachefsは改善するはずです:)
ZFSは非常に堅牢であることを付け加えることができます。これは主にその起源（2001年にSun Microsystemsによって開発されたもの）のおかげです。現在利用可能なオープンソースバージョンは、Sun Microsystemsが買収した後にOracleがZFSソースを閉鎖した後、オープンソースコミュニティによってさらに開発された、約10年前にSun Microsystemsがリリースした最新のオープンソースバージョンのフォークです。
Oracle自身も、エンタープライズストレージシステムで使用されているZFSのクローズドソースバージョンを維持しています。
ただし、ZFSは非常に強力であるため、微調整できる点は数多くあります。また、メンテナンスが実際に簡単な、私が取り組んだ数少ないストレージファイルシステムの1つでもあります。 RAID5セットアップからRAID6（より正確にはRAID-Z1からRAID-Z2）にプールを移行する必要があるケースが1つありました。通常、このような操作は、すべてのデータをコピーして、RAIDを再構成し、データをコピーして戻すことを意味します。ZFSでは、セカンダリストレージを接続し、1つのコマンドでプールをコピーして、必要に応じてアレイを再構成します。 、別のコマンドでプールをコピーして戻します。
ただし、いくつかの落とし穴があります。
- ZFSからメリットを得るには、ZFSにディスク自体を処理させる必要があります。したがって、ドライブコントローラーはJBODをサポートする必要があり、ZFSはディスクを直接認識します。すべてのRAID構成はZFSで処理されます。スクラブやその他のタスクにパリティデータを使用するため、RAIDコントローラーによって非表示にすることはできません。
- 他の人が述べたように、ECCメモリは強く推奨です。 ZFSはそれを必要としませんが、RAMに書き込まれるものはすべて不変であり、破損しないことを十分に期待しています。したがって、ECC以外のシステムで実行する場合RAMでメモリが不良になると、ZFSはアレイをスクラブしている間に実際にデータを破壊する可能性があります（スクラブとは、ZFSがプールからデータを読み取り、他のドライブに保存されているパリティ情報から何を読み取るべきかを計算し、見つかったエラーを修正します）。
- ZFSはデータ損失の防止に非常に優れていますが、そのRAID-Z1にはRAID5と同じ問題があります。大きな（1TB +）ドライブの大きなアレイは、ドライブのUREレートが高すぎる場合、アレイを再構築するときに単一のディスク障害の後で完全に失敗する可能性があります。数学的に再構築しながら、残りのドライブからパリティからすべてのデータを読み取るだけなので、ほぼ保証されます。ドライブのサイズが原因で回復不可能な読み取りエラー。ストレージシステムの操作に精通しておらず、たまたま自分が何をしているかを知っている場合は、RAID6/RAID-Z2を実行してください。
初心者や家庭環境では、FreeNASをお勧めします。メンテナンスが簡単でセットアップも簡単で、初心者には適しています。