最近、非 ECC RAM と一般的なファイルシステムを備えたシステムの破損率に関する驚くべき統計を読みました。Google で調べたところ、破損を防ぐには、ECC RAM を備えたシステムで ZFS を実行するのがおそらく最善の方法のようです。その情報のほとんどは、NAS に関する議論の文脈で語られています。
ソース マシン上でファイルが破損しておらず、ネットワーク経由で完全に転送されていると仮定すると、このようなシステムがあれば、ファイルをアーカイブするのに役立つことがわかります。
Google で調べられなかったのは、信頼性の低いコンピューターでファイルを操作しているときに、最も信頼性の高い NAS でファイルをホストする (またはバックアップする) ことに何の意味があるのかということです。また、Samba (FreeNAS や OpenIndiana などの ZFS 対応 OS の最新バージョンが何であれ) のエラー修正に関する適切な情報も見つけることができませんでした。Samba がエラーを起こしやすいのであれば、他のほとんどすべては無意味です (私がすべてをハッシュしてすべての転送を検証しない限り)。
ビットの劣化などを心配したくない場合は、現在のシステムを（比喩的に）捨てて、（ミニ）サーバーグレードのハードウェアに置き換える必要がありますか？ また、その方法を選択した場合、ZFS の実行以外のリソースを合理的に確保できると期待できますか？ 数千ドルを費やすことなく？
私の使用例:
私は、再生（映画やその他のメディアなど）以外にも関心があります。自宅のコンピューターでプログラミング作業を頻繁に行っています。たとえば、さまざまなプロジェクト用の SQLite データベース ファイルの数は増え続けています。そのうちの 1 つが破損すると問題になります。また、アーカイブするだけでなく、整理したり、タグ付けしたりしたい家族や休暇の写真が何ギガバイトもあります。銀行を経営しているわけではありませんが、交換が難しいものがあり、それが「静かに破損」するなんて考えたくないのです。
答え1
ZFS は、どのハードウェア上で実行されるかについて非常にこだわりがあります。
チップセット、グラフィック カード、ディスク ファームウェア バージョンなどを正確に揃える必要があるという意味ではなく、ハードウェアによって提供される機能という意味です。ZFS はハイエンド サーバー ソリューションとして設計されており、ZFS が行う特定の仮定はそれを反映していることに注意してください。
ZFSが重要なデータを保存するのに非常に優れている理由の大部分は、検出と検出の両方を同時に行えるように設定できることです。そして正しいストレージのエラー。これは、どこかで 1 ビットが反転するなどの些細なエラーの場合もあれば、複数のディスクが同時にクラッシュするなどの壊滅的なエラーの場合もあります。ストレージ レイアウトの冗長性しきい値を超えている限り (たとえば、raidz2 vdev で同時に問題が発生するディスクは 2 つまで)、ZFS は冗長データを使用してエラーを修正できます。さらにエラーが発生する場所と方法によっては、(半) 正常なシステム パニックや単純な I/O エラーにつながる可能性があります。
正しく実行すれば、定期的に ZFS プールをスクラブするようにシステムを設定することもできます。これにより、問題になる前に劣化を検出し、通知を受け取ることができるため、問題になる前に、データの保持に問題のあるストレージ デバイスの交換を検討できます。
しかし、その偉大さはRAM が信頼できるかどうかに依存します。こうした検証、修正、書き換えなどはすべて主に RAM で行われます。ハイエンド サーバーでは、ECC RAM 以外は見つかりません。
ZFS は、プール メタデータ、ファイル システム メタデータ、およびユーザー データを同じ方法で保護 (および処理) します。ここに実質的な違いはありません。
ワークステーションシステムでRAMビット反転が発生した場合、ビット反転したデータをZFSに書き込むと、ビット反転したデータがZFSが最終的にディスクに書き出すデータの基礎となります。これは明らかに悪いことです。ファイルが破損するからです。しかし、ビット反転したデータはZFSに関しては正しいこれは実際には良いなぜなら、通常のZFSリカバリ方法がすべて機能することを意味するからです。確かに、問題のファイルの最新のコピーは破損していますが、いずれにしても腐敗しているだろうどのようなファイルシステムを使用していたとしても。ZFSのスナップショットを活用できる少なくとも、破損していないコピーを過去に戻すことができるように。zfs 自動スナップ定期的に、短い間隔でファイルシステムのスナップショットを作成し、大まかな履歴を遡って保存しておき、必要になるまで忘れておくことができます。(たとえば、10 分間隔で 10 個のスナップショット、1 時間間隔で 50 個のスナップショット、6 時間間隔で 30 個のスナップショットなど)。ZFS ではスナップショットは実質的に無料です。ZFS を使用する場合、スナップショットを使用する同じように。
ZFS を実行するストレージ サーバーで、ビット反転または 1 つ以上のビットのスタックなどの不良 RAM が発生し、ストレージ サーバーに ECC RAM が搭載されている場合は、これが検出され、イベントがログに記録されるか、システムが停止します (エラーを修正できない場合)。いずれの場合も、サーバーに保存されているデータの整合性は保持されます。ZFS ストレージ サーバーに非 ECC RAM が搭載されている場合は、エラーはすべてのデータとメタデータに伝播する可能性がありますZFSは、実際にはコンピュータの想像上の産物に過ぎないエラーを「修正」しようとします。最悪のシナリオとしては、実際に人々に起こることだ、このためプール全体が破壊され、すべてのデータが失われます。ストレージレベル/vdev レベルの冗長性もここでは役に立ちません。他のほとんどのファイル システム (自動修正動作なし) では、ビット フリップによって直接影響を受けた 1 つの場所のみが破損し、ファイル システム メタデータにこれが発生した場合でも、従来のファイル システム チェッカーと回復ツールによって簡単に修正できます。ZFS にはこの脱出口がありません。fsck.zfs がありません。（があるzpool スクラブただし、プールが修理不能なほど壊れている場合は、この方法は使えません。
Google で調べることができなかったのは、信頼性の低いコンピューターでファイルを操作しているときに、最も信頼性の高い NAS でファイルをホストする (またはバックアップとして使用する) ことに何の意味があるのかということです。
つまり、信頼できるデータ リポジトリがあるということです。データが NAS に送られると、破損の心配はありません。破損があった場合は自動的に修復されるか、または問題について通知されます (ZFS の場合は I/O エラー経由)。信頼性の低いシステムで作業している間はデータが破損している可能性がありますが、破損していないことがわかっているコピーを入手できる場所があります。NAS システムだけに ECC RAM、ZFS、高品質のストレージ監視とアラートが設定されている場合でも、これは利点となります。
その後、必要に応じて、予算が許す限り、他のシステムに (特に) ECC RAM を追加して、最後の穴を埋めることができます。
ビットの劣化などを心配したくない場合は、現在のシステムを（比喩的に）捨てて、（ミニ）サーバーグレードのハードウェアに置き換える必要がありますか？ また、その方法を選択した場合、ZFS の実行以外のリソースを合理的に確保できると期待できますか？ 数千ドルを費やすことなく？
まず、サーバーグレードのハードウェアは実際には必要ありません。必要なのは主にECC RAM（およびECC RAMをサポートするCPUとメモリコントローラ/チップセット）です。十分に信頼性の高い永続的なストレージ、そして理想的には、システムの実行中にディスクの追加と削除が簡単にできるケース。これは非常に高価である必要はなく、もちろん「数千ドル」かかる必要もありません。
第二に、ZFS は RAM を必要としますが、主にキャッシュ用です。ほとんどのワークロードでは、8～16 GB の RAM で十分であり、24～32 GB (「コンシューマー」マザーボードでも簡単に手に入ります) は、高品質のブランド ECC RAM を購入する場合でも、まだ手頃な価格です。ZFS は CPU をそれほど消費しません。大量の CPU を必要とするように設定することもできます (ゾル、sha256、gzip-9 圧縮、および重複排除を組み合わせて設定することで実現できますが、必ずしもそうする必要はありません。私のシステムは ZFS を実行しており、それほど高性能ではありません (FX-6100 CPU をクロックダウン)。あらゆる場所で sha256 を使用しており、純粋なシーケンシャル I/O でもディスクが制限要因となります。スクラブの最初の小さなランダム読み取り部分を過ぎると、スクラブのスループットは、dd基盤となるストレージ デバイスからの raw の場合とほぼ同じになり、CPU に余裕があります。
答え2
Google で調べることができなかったのは、信頼性の低いコンピューターでファイルを操作しているときに、最も信頼性の高い NAS でファイルをホストする (またはバックアップとして使用する) ことに何の意味があるのかということです。
何か問題が起こる可能性は累積します。
言い換えると (数字は偽です)、
NAS で問題が発生する可能性が 10% あり、
他のデバイスで問題が発生する可能性が 10% ある場合、
NAS から何かを読み取って他のデバイスで再生するときに失敗する可能性が 20% あります。
Sambaのエラー訂正に関する良い情報も見つけることができません
どの samba バージョンか。3 つのバージョン間でプロトコルがかなり変更されました。
少しでもエラーが発生しやすい場合は、他のほとんどすべては無意味です (私が個人的にすべてをハッシュし、すべての転送を検証しない限り)。
エラーのリスクは常に存在します。エラーは必ず発生します。エラーは検出され、修正されます (チェックサムなどにより)。RAM を使用する場合、これは必ずしも当てはまりません。RAM はパリティや ECC を使用することで改善できます。ただし、これらの問題は比較的起こりにくく、金メッキ (および高価) の設計と「十分」な設計のバランスを取る必要があります。
このバランスは、一部の人にとってはまったく異なります (たとえば、銀行は完璧なものを求めています)。映画を再生するための個人用システムでは、ECC を使用する必要はないでしょう。
答え3
接続:
Samba の Web サイトでドキュメントを読もうとしましたが、Samba にエラー訂正機能があるかどうかはわかりませんでした。最悪のケース、つまり Samba がエラーのない基盤ネットワークに依存していると仮定するしかありませんでした。基盤ネットワークが TCP/IP の場合、唯一の保護手段は弱いチェックサムのようです。
最終的に iSCSI を選択しました。これは、CRC32C アルゴリズムを使用するオプションのヘッダーとデータ ダイジェストをサポートしているためです。これは TCP/IP チェックを超えたものです。
何かメリットはありますか？
私にとっての答えは「少なくとも1つのシナリオではイエス」です。信頼できるプログラムを使用して、サーバーグレードのZFSマシンにファイルをバックアップできます。その後、定期的にチェックできます。おそらく元のマシン上の変更されていないファイルは実は変更されていません。不一致がある場合は、サーバーからバックアップを復元できます。
唯一の弱点は、信頼性の低い消費者向けマシンでファイルが意図的に変更されている場合です。そのような短い期間に破損が発生する可能性は非常に低いため、許容範囲内だと思います。変更中に破損が発生したことに気付いた場合は、増分バックアップを頼りにすることができます。
私のコンピューターを、ZFS を実行できるほど強力なサーバーに置き換え、プライマリ コンピューターとして使用するためのリソースを残しておくことはできますか?
おそらくそうでしょうが、非常に高価になるでしょう。私は上記のシナリオに満足しているので、これを試みるつもりはありません。