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