mdadmによるビット腐敗の検出と修正

私は自宅のLinuxボックスnasですべてのHDDを再編成しようとしています。データ保護のためにmdadm raidを使用し、アレイを再形成するための柔軟性を望んでいます。ただし、これにmdadmを使用する前に、bit rotの処理方法を知りたいと思います。具体的には、回復不能な読み取りエラーメッセージがHDDから送信されないビットロットの種類。

NASの8台のディスクで少なくとも21TBのHDDを使用する可能性が高いことと、HDD の障害の可能性に関するさまざまな引用を考えると、1つのディスク障害からの再構築中に合理的に遭遇する可能性が高いと考えています残りのディスクで何らかの形のビットが腐敗しています。ドライブの1つで回復不能な読み取りエラーが発生し、ドライブが実際にエラーとして報告する場合、raid6で問題ないはずです（そうですか？）。ただし、ディスクから読み取られたデータが不良であるが、ディスクによってそのように報告されていない場合、raid6を使用してもこれをどのように自動的に修正できるかわかりません。これは私たちが心配する必要があるものですか？それは2010年であり、RAID5はまだ機能している記事を考える、そして自宅や職場での私自身の成功した経験では、物事は必ずしも話題の言葉やマーケティングが信じているほど悲観的ではありませんが、HDDが故障したからといってバックアップから復元する必要はありません。

使用パターンが、最大で数回書き込み、時々読み取ることを考えると、データのスクラブを実行する必要があります。私は上を参照 ウィキarchlinux 用のmdadmコマンドスクラビングデータとして配列を

echo check > /sys/block/md0/md/sync_action

その後、進行状況を監視します

cat /proc/mdstat

これは、すべてのディスクのすべてのセクターを読み取り、データがパリティと一致すること、およびその逆を確認するように思えます。私は、「チェック」操作が自動修正できず、検出するだけで、修正するのはユーザーに任せるという重要な状況があることをドキュメントに強調していることに気付きますが。

ビット腐敗からの保護を最大化するためにどのmdadm RAIDレベルを選択する必要があり、どのようなメンテナンスや他の保護手順を実行する必要がありますか？そして、これは私を何から守らないのでしょうか？

編集：私はRAID対ZFSまたは他の技術QAを開始するつもりはありません。mdadm raidについて具体的に知りたい。それが、私がSuperUserではなくUnixとLinuxで尋ねている理由でもあります。

編集：答えは次のとおりです： mdadmは、データスクラブ中にディスクシステムによって報告されたUREのみを修正し、スクラブ中にサイレントビット腐敗を検出できますが、修正できません/修正しませんか？

率直に言って、あなたがRAIDZ2 ZFSを拒否するのはむしろ驚くべきことです。Linux MDではないという事実を除いて、ニーズにほぼ完全に合っているようです。私はZFSを大衆にもたらすための十字軍ではありませんが、単純な事実は、あなたの問題はZFSが解決するためにゼロから設計された問題の一種であることです。RAID（任意の「通常の」RAID）に依存して、冗長性の低下または非冗長の状況でエラーの検出と修正を提供することは、リスクが高いようです。ZFSがデータエラーを適切に修正できない場合でも、少なくともエラーを検出し、問題があることを知らせることができるため、修正措置を講じることができます。

ZFSを使用して定期的にフルスクラブを実行する必要はありませんが、推奨される方法です。ZFSは、ディスクから読み取られたデータが、データの読み取り中に書き込まれたものと一致することを確認し、不一致の場合は、（a）冗長性を使用して元のデータを再構築するか、（b）I / Oエラーを報告しますアプリケーション。また、スクラブは低優先度のオンライン操作であり、高優先度とオフラインの両方であるほとんどのファイルシステムでのファイルシステムチェックとはまったく異なります。スクラブを実行していて、スクラブ以外がI / Oを実行したい場合、スクラブはその間後部座席に座ります。ZFSスクラブは、RAIDスクラブとファイルシステムのメタデータおよびデータの両方の代わりになります 整合性チェックは、RAIDアレイをスクラブしてビットの腐敗を検出するよりもはるかに徹底的です（データが意味をなすかどうかはわかりませんが、RAIDコントローラーによって正しく書き込まれただけです）。

ZFSの冗長性（RAIDZ、ミラーリングなど）には、スクラブ中に未使用のディスクの場所の整合性をチェックする必要がないという利点があります。ツールは割り当てブロックチェーンを歩くため、スクラブ中は実際のデータのみがチェックされます。これは、非冗長プールの場合と同じです。「通常の」RAIDの場合、RAIDコントローラー（ハードウェアまたはソフトウェア）が実際に関連するデータを把握していないため、すべてのデータ（ディスク上の未使用の場所を含む）をチェックする必要があります。

RAIDZ2 vdevを使用すると、2台のドライブに冗長性があるため、別のドライブの障害による実際のデータ損失の危険にさらされる前に、2つの構成ドライブが故障する可能性があります。これは基本的にRAID6と同じです。

ZFSでは、ユーザーデータとメタデータの両方のすべてのデータがチェックサムされます（選択しない場合を除きますが、推奨されません）。これらのチェックサムは、何らかの理由でデータが変更されていないことを確認するために使用されます。繰り返しますが、チェックサムが期待値と一致しない場合、データは透過的に再構築されるか、I / Oエラーが報告されます。I / Oエラーが報告された場合、またはスクラブで破損したファイルが特定された場合、そのファイルのデータが破損している可能性があることがわかり、その特定のファイルをバックアップから復元できます。アレイ全体を復元する必要はありません。

単純な、二重パリティであっても、RAIDは、たとえば1つのドライブに障害が発生し、もう1つのドライブがディスクからデータを誤って読み取るような状況から保護しません。1つのドライブに障害が発生し、他のドライブのいずれかからシングルビットフリップが発生したとします。突然、破損が検出されず、満足できない限り、少なくともそれを検出する方法が必要になります。そのリスクを軽減する方法は、ディスク上の各ブロックのチェックサムをチェックし、チェックサムがデータと共に破損しないことを確認することです（高頻度書き込み、孤立した書き込み、ディスク上の誤った場所への書き込みなどのエラーから保護します）。チェックサムが有効になっている限り、ZFSはまさにそれを実行します。

唯一の本当の欠点は、デバイスを追加してRAIDZ vdevを簡単に拡張できないことです。そのための回避策があり、通常はvdev内のデバイスとしてスパースファイルのようなものが関係し、非常に頻繁に「自分のデータであればこれをしない」と呼ばれます。したがって、RAIDZルートを使用する場合（RAIDZ、RAIDZ2、またはRAIDZ3を使用するかどうかに関係なく）、各vdevに必要なドライブ数を事前に決定する必要があります。VDEV内のドライブの数が固定されているが、あなたがすることができ、徐々に（VDEVの冗長しきい値内に収まるように確認すること）より大きな容量のものでドライブを交換し、完全な再同期化を可能にすることにより、VDEVを育てます。

この答えは、私が見つけたさまざまな証拠に基づいた推論の産物です。私はカーネル開発者ではないので、カーネルLinuxの実装がどのように機能するのかわかりません。私は、カーネルLinuxが正しい選択をしていると思います。間違っていない限り、私の答えは当てはまります。

多くのドライブは、ECC（エラー修正コード）を使用して読み取りエラーを検出します。データが破損している場合、カーネルはECCサポートドライブからそのブロックのURE（回復不能な読み取りエラー）を受信する必要があります。これらの状況下（および以下に例外があります）で、破損した、または空のデータを正常なデータにコピーすると、狂気になります。この状況では、カーネルはどちらが良いデータで、どれが悪いデータであるかを知る必要があります。よると、それは2010年で、RAID5はまだ動作...記事：

少なくとも数社のアレイベンダーが使用していることがわかっているこの代替案を検討してください。RAIDボリューム内のドライブがUREを報告すると、アレイコントローラーはカウントをインクリメントし、パリティからブロックを再構築することでI / Oを満たします。次に、UREを報告したディスクで書き換えを実行し（場合によっては検証を行います）、セクターが不良である場合、マイクロコードが再マッピングされ、すべて正常になります。

ただし、ここで例外があります：ドライブがECCをサポートしていない場合、ドライブがデータ破損についてある、またはファームウェアが特に機能していない場合、UREは報告されず、破損したデータがカーネルに提供されます。データが一致しない場合：2つのディスクRAID1またはRAID5を使用している場合、パリティが1つしかないため、非劣化状態であっても、カーネルはどのデータが正しいかを知ることができないようですブロックし、報告されたUREはありませんでした。3ディスクRAID1またはRAID6では、単一の破損した非UREフラグ付きブロックは、冗長パリティと（他の関連するブロックと組み合わせて）一致しないため、適切な自動回復が可能です。

ストーリーの教訓は、ECCでドライブを使用することです。残念ながら、ECCをサポートするすべてのドライブがこの機能を宣伝しているわけではありません。一方、注意してください。2ディスクRAID1（または2コピーRAID10）で安価なSSDを使用した人を知っています。ドライブの1つが、特定のセクターの読み取りごとにランダムに破損したデータを返しました。破損したデータは、正しいデータに自動的にコピーされました。SSDがECCを使用し、適切に機能していれば、カーネルは適切な修正措置を講じているはずです。

必要な保護のために、RAID6 + 2つの場所での通常のオフサイトバックアップを使用します。

とにかく個人的には週に1回スクラブし、データの重要性と変更速度に応じて、夜間、毎週、毎月バックアップします。

コメントするのに十分な担当者がいませんが、Linuxのmdadmシステムはエラーを修正しません。たとえば、RAID6のスクラブ中にエラーを「修正」するように指示した場合、矛盾がある場合は、データ部分が正しいと仮定してパリティを再計算することで「修正」します。

ビット腐敗。承知しました...

SEAGATEと話をする必要があると思います。（それを忘れるのは言い訳です）？すべてのドライブに100ビットECC修正があり、最初に腐敗を証明する必要があります。
できませんね。（心配するのはFUDのことですか？）幽霊への恐怖や＃13のような？ここでは行われません。ゼロ証明が起こりました。さらに悪いことに、原因の証拠もありません。

最初にビット腐敗の意味を定義します。ouch ... HDD：ECCは、ECC 100ビットストレージに対してデータ（1ビットでも）をチェックします。間違っている場合は修正し、SMARTエンジンが故障し続ける場合は、SASドライブ上で、クラスターまたはセクターを論理的に良好なものに置き換えます。スペアクラスタを使用します。これにより損傷が修復されます。はい、IBMの最初のドライブからNOWまで、すべてのドライブが最初から最後まで不良ビットを増やします。しかし、現在は自己修復を行っています。Seagateのホワイトペーパーをすべてお読みください。無限にあり、ドライブの仕組みを学びます。OK？

これは、スペアがなくなるまで継続し（hdd brain、smart）、SMARTはEND OF LIFEを叫びます。（またはHPよりも早い）HP P420コントローラーでは、これを常に監視しています。私も私に電子メールを送り、NEAR OUT OF SPAREクラスターを示しています。いつか予備品がもっと速くなり、間もなく運命の兆候が現れるだろう（10歳は確かであり、ジャンキーなSATAが少ない。

私はBOGUSを呼び出し、ビット腐敗でFUDを実行します。

私の推測では、誰かのおもちゃのPCがデータを間違って書いたのは、どんな理由であれです。ECCメモリを実行していない?? oops、実サーバーにはECC RAMがあります。ウイルス感染。または書き込み中に電源が失われた（UPSなし？）？またはメモリが不良です。またはESD損傷。またはPSUが大量のノイズを発している（悪い）

ここでFUDを呼び出します。ごめんなさい、