ハードドライブでビットが腐敗するのは本当の問題ですか？それについて何ができますか？

友人がビット腐敗の問題について話している-ドライブのビットがランダムに反転し、データが破損している。非常にまれですが、十分な時間があると問題になる可能性があり、検出することはできません。

ドライブはそれを不良セクタとは見なさず、バックアップはファイルが変更されたと判断します。整合性を検証するためのチェックサムはありません。RAIDセットアップでも、違いは検出されますが、どのミラーコピーが正しいかを知る方法はありません。

これは本当の問題ですか？もしそうなら、それについて何ができますか？私の友人はソリューションとしてzfsを推奨していますが、Solarisとzfsを使用して、職場でファイルサーバーを平坦化することは想像できません。

最初に：ファイルシステムにチェックサムがない場合がありますが、ハードドライブ自体にチェックサムがあります。たとえば、SMARTがあります。もちろん、1ビットが多すぎると、エラーを修正できません。そして、もしあなたが本当に不運なら、チェックサムが無効にならないようにビットが変わる可能性があります。エラーは検出されません。したがって、厄介なことが起こる可能性があります。しかし、ランダムなビットフリッピングによりデータが即座に破損するという主張は偽です。

ただし、はい、ハードドライブに数兆ビットを入れても、そのように永久に残ることはありません。それは本当の問題です！ZFSは、データが読み取られるたびに整合性チェックを実行できます。これはハードドライブが既に行っていることと似ていますが、一部のスペースを犠牲にするもう1つの安全策であるため、データ破損に対する回復力が向上しています。

ファイルシステムが十分に優れている場合、検出されずにエラーが発生する可能性が非常に低くなるので、それ以上気にする必要はなく、使用しているデータストレージ形式にチェックサムを組み込むことを決定できます。不要。

どちらにしても：いいえ、検出することは不可能ではありません。

しかし、ファイルシステムだけでは、すべての障害を回復できるという保証はありません。それは特効薬ではありません。エラーが検出された場合の対処方法のバックアップと計画/アルゴリズムが必要です。

はい、それは主にドライブのサイズが大きくなるにつれて問題になります。ほとんどのSATAドライブのURE（修正不可能な読み取りエラー）レートは10 ^ 14です。または、統計的に12TBのデータを読み取るたびに、ドライブベンダーは、ドライブが読み取り失敗を返すと言います（通常、ドライブの仕様書で確認できます）。ドライブは、ドライブの他のすべての部分で引き続き正常に機能します。一般に、エンタープライズFCおよびSCSIドライブのUREレートは10 ^ 15（120TB）であり、SATAドライブの数は少なくなります。

まったく同時にディスクの回転が停止するのを見たことはありませんが、raid5ボリュームがこの問題に遭遇しました（5年前に5400RPMコンシューマPATAドライブで）。ドライブが故障し、死んでいるとマークされ、スペアドライブの再構築が行われます。問題は、再構築中に2番目のドライブがその1つの小さなデータブロックを読み取れないことです。誰がレイドを行っているかによって、ボリューム全体が死んでいるか、その小さなブロックだけが死んでいるかもしれません。1つのブロックだけが死んでいると仮定すると、読み込もうとするとエラーが発生しますが、書き込むとドライブは別の場所に再マップします。

保護する方法は複数あります。二重ディスク障害から保護するraid6（または同等のもの）が最適です。追加の方法はZFSなどのURE対応ファイルシステムであり、より小さいRAIDグループを使用するため、統計的にUREドライブにヒットする可能性が低くなります制限（ミラーの大きなドライブまたはRAID5の小さなドライブ）、ディスクスクラブとSMARTも役立ちますが、それ自体は保護ではありませんが、上記の方法の1つに加えて使用されます。

私はアレイで3000近くのスピンドルを管理しており、アレイは潜在的なUREを探してドライブを常にスクラブしています。そして、raid6の代わりにraid5を使用していて、ドライブの1つが完全に死んだ場合、それらのかなり一定したストリームを受け取ります（ドライブ障害の前にそれを修正して警告する）。特定の場所にヒットすると問題が発生します。

ハードドライブは通常、データビットを単一の磁区としてエンコードしません。ハードドライブのメーカーは、磁区が反転し、ドライブのエラー検出と修正を組み込む可能性があることを常に認識しています。

ビットが反転した場合、ドライブには十分な冗長データが含まれており、次回そのセクターが読み取られるときに訂正できます。ドライブのSMART統計をチェックすると、「修正可能なエラー率」としてこれを確認できます。

ドライブの詳細に応じて、セクタ内の複数の反転ビットから回復することさえできるはずです。静かに修正できる反転ビットの数には制限があり、おそらくエラーとして検出できる反転ビットの数には別の制限があります（修正するのに十分な信頼できるデータがなくなったとしても）

これはすべて、ハードドライブが発生するとほとんどのエラーを自動的に修正し、残りのほとんどを確実に検出できるという事実につながります。単一のセクターで多数のビットエラーが発生する必要があります。これらはすべて、そのセクターが再度読み取られる前に発生し、エラーは、内部エラー検出コードが再度有効なデータとして認識するようにする必要があります。黙って失敗するでしょう。それは不可能ではなく、非常に大規模なデータセンターを運営している企業はそれが発生することを確認します（むしろ、発生し、発生することを確認しません）。

最新のハードドライブ（199x以降）には、チェックサムだけでなく、かなり「ランダムな」ビット腐敗を検出および修正できるECCもあります。http://en.wikipedia.org/wiki/SMARTを参照してください。

一方、ファームウェアとデバイスドライバーの特定のバグは、まれにデータを破損する可能性があり（そうでない場合はQAがバグをキャッチします）、より高いレベルのチェックサムがないと検出が困難になります。SATAとNICの初期のデバイスドライバーは、LinuxとSolarisの両方でデータを破損していました。

ZFSチェックサムは、主に低レベルソフトウェアのバグを対象としています。Hypertableのような新しいストレージ/データベースシステムには、ファイルシステムのバグから保護するために、更新ごとにチェックサムもあります:)

理論的には、これが懸念の原因です。実際には、これは、子/親/祖父母のバックアップを保持する理由の一部です。IMO、少なくとも5年間は年次バックアップを保持する必要があります。これよりも先に戻った場合、ファイルは明らかにそれほど重要ではありません。

誰かの脳をゆがめる可能性のあるビットを扱っていない限り、リスクと報酬がファイルシステムを変更するまでには至っていないと思います。

はい、それは問題です。

これがRAID6が流行している理由の1つです（また、HDサイズを大きくすると、アレイを再構築する時間が長くなります）。2つのパリティブロックを使用すると、追加のバックアップが可能になります。

RAIDシステムは、ディスクブロックを定期的に読み取り、パリティをチェックし、不良ブロックが見つかった場合は交換するRAIDスクラビングも実行します。

RAIDに関するOPの声明に関して、どのデータが良いか悪いかを理解していない。

RAIDコントローラーは、データのストライプごとに少なくとも（奇数/偶数）パリティビットを使用します。これはすべてのものです。ディスク上のデータストライプとパリティ（バックアップ）データストライプ。

つまり、冗長性のためのストライピング（RAID 5/6）があるRAIDタイプの場合、コントローラーは、元のデータストライプが変更されたかどうか、および冗長データストライプが変更されたかどうかを正確に判断できます。

RAID6のような2番目の冗長ストライプを導入する場合、3つの異なるドライブ上の3つのデータストライプが破損している必要があり、それらはすべて同じ実際のファイルデータに対応しています。ほとんどのRAIDシステムは比較的小さなデータストライプ（128 kb以下）を使用するため、「ビットロット」が同じファイルの同じ128 kbに並ぶ可能性は事実上不可能です。

はい、それは現実世界の問題ですが、問題はそれを心配すべきかどうかです。

写真でいっぱいのhddしか得られなかった場合、努力する価値はないかもしれません。それは重要な科学的データでいっぱいであり、別の種類の物語かもしれません、あなたはアイデアを得ました。