mdadmによるビット腐敗の検出と修正
自宅のLinuxボックスNASにすべてのHDDを再編成しようとしています。データ保護とアレイの再形成のためのmdadm raidを使用したいと考えています。ただし、これにmdadmを使用する前に、それが bit rot をどのように処理するかを知りたいと思います。具体的には、回復不能な読み取りエラーメッセージがHDDから送信されないビット腐敗の種類。
NASの8つのディスクで少なくとも21TBのHDDを使用する可能性が高く、HDDで 確率 の 失敗 に関するさまざまな見積もりを使用していることを考えると、単一のディスク障害からの再構築私は、残りのディスクで何らかの形のビットの腐敗に遭遇する可能性がかなり高いです。ドライブの1つで回復不可能な読み取りエラーである場合、ドライブが実際にそれをエラーとして報告するので、raid6で問題ないはずです（そうですか？）。ただし、ディスクから読み取られたデータが不良であるが、ディスクによってそのように報告されていない場合、raid6を使用しても、これを自動的に修正する方法がわかりません。これは私たちが心配する必要があるものですか？記事 それは2010年で、RAID5はまだ機能します 、および自宅や職場での私自身の成功体験を考えると、流行語やマーケティングで信じられているように、物事は必ずしも運命や憂鬱ではありませんが、私は嫌いですHDDが故障したからといって、バックアップから復元する必要があります。
使用パターンは、最大で数回、時々読み取ることになるため、 data scrubbing を実行する必要があります。私は archlinux wiki のmdadmコマンド data scrubbing 配列を
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ではないため、exceptを除いて、ニーズにほぼ完全に適合しているようです。私はZFSを大衆にもたらすための十字軍に参加していませんが、簡単な事実は、あなたの問題はZFSが根本から設計された問題の1つであることです 。 RAID（「通常の」RAID）に依存してエラーの検出と修正を行うと、冗長性が低下した、または冗長性のない状況でリスクが発生する可能性があります。 ZFSがデータエラーを適切に訂正できない状況でも、少なくともエラーを検出して、エラーがあることを通知できます問題があり、是正措置を取ることができます。
推奨される方法ですが、ZFSを使用して通常のフルスクラブを実行するhaveすることはありません。 ZFSは、ディスクから読み取られたデータが、データの読み取り時に書き込まれたデータと一致することを確認します。不一致の場合は、（a）冗長性を使用して元のデータを再構築するか、（b）にI/Oエラーを報告しますアプリケーション。また、スクラブは低優先度のオンライン操作であり、高優先度とオフラインの両方が可能なほとんどのファイルシステムのファイルシステムチェックとはかなり異なります。スクラブを実行していて、スクラブ以外の何かがI/Oを実行したい場合、その間、スクラブは後部座席を使用します。 ZFSスクラブは、RAIDスクラブとファイルシステムメタデータとデータの整合性チェックの両方の代わりをするため、さらに多くのRAIDアレイをスクラブしてビットの腐敗を検出するだけでは不十分です（データがまったく意味をなしているかどうかはわかりませんが、RAIDコントローラーによって正しく書き込まれたことだけがわかります）。
ZFSの冗長性（RAIDZ、ミラーリングなど）には、スクラブ中に未使用のディスクの場所の整合性をチェックする必要がないという利点があります。ツールがアロケーションブロックチェーンをウォークするため、スクラブ中に実際のデータのみがチェックされます。これは、非冗長プールの場合と同じです。 「通常の」RAIDの場合、すべてのデータ（ディスク上の未使用の場所を含む）をチェックする必要があります。これは、RAIDコントローラー（ハードウェアまたはソフトウェア）が実際に関連するデータを認識していないためです。
RAIDZ2 vdevsを使用することにより、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のスクラブ中にエラーを「修正」するように指示した場合、不整合があると、データ部分が正しいと想定してパリティを再計算することにより、「修正」します。