書き込みホール：どのRAIDレベルが影響を受けますか？
RAIDZの利点を理解するための旅で、write holeの概念に出くわしました。
このページ で説明されているように、書き込みホールは、書き込み中に電力が失われたときに、アレイのディスク間で発生する不整合です。このページでは、RAID-5/6（データが書き込まれた後、パリティが計算される前に電源が失われた場合）とRAID-1（データが1つのディスクに書き込まれ、他のディスクには書き込まれない）の両方に影響することも説明されています、そしてそれは再同期/スクラブ中、または（悲惨なことに）ディスクの1つの再構築中にのみ検出できる陰湿な問題です...しかし、 mostoftheothersources パリティベースのRAIDレベルにのみ影響を与えるため、それについて説明します。
私が理解していることから、穴が含まれているディスクからの読み取りはガベージを返すため、これはRAID-1でも問題になる可能性があると思うので、everyRAIDレベルかどうか？実装依存ですか？ソフトウェアRAIDのみ、またはハードウェアコントローラーにも影響しますか？ （追加：この点でmdadmはどのように機能しますか？）
書き込みホールは、すべてのRAIDレベルに影響を与える可能性がありますが、RAID-0です。ストライプ化（RAID-4/5/6）構成とミラー化（RAID-1）構成の両方が脆弱である可能性があります。これは、2つ以上のディスクではアトミックな書き込みが不可能なためです。
問題は実装に依存するため、「可能性があります」と言います。 RAID-Zなどの次世代ファイルシステムソリューションは別として、従来のソフトウェアRAID実装でもこれに対処する方法が見つかりました：mdadmは 比較的最近 専用キャッシュを使用するジャーナル機能を導入この機能を使用しないことを選択した場合でも、ディスクはそれを回避し、クリーンでないシャットダウンのたびに再同期を強制します。これにより、書き込みホールが発生するとすぐにキャッチして解決します。
助けてくれた#zfs ircチャンネルに感謝します！
RAIDキャッシュまたはキャッシュ整合性検証の他の方法がRAIDに必要なのはこのためです。すべてのRAIDカードにはバッテリーバックアップキャッシュが必要であり、すべてのストレージコントローラーにはミラーキャッシュが必要です。ソフトウェアレイドについては、良い答えはないと思います。 raid Zでも停電で失敗する可能性があると思います。
RAIDアレイの「書き込みホール」とは、2の可能な定義があると思います。
あなたが言及したページは、「書き込みホール」をとって、RAIDアレイの不整合を意味しています。これを理解するには、RAIDアレイの動作を考慮する必要があります。書き込み操作は、アレイの異なるディスクに送信されます。ただし、ディスクは独立しているため、書き込み操作が実際に（ディスクによって）物理メディアにコミットされる順序は保証されません。つまり、RAIDアレイにブロックを書き込む場合、書き込み操作はアトミックではありません。これは、アレイの通常の操作では問題になりません。ただし、停電などの重大な障害が発生した場合などです。
RAIDアレイの内部不整合は、何らかのデータ冗長性を持つすべてのRAIDレベルで発生する可能性があります。RAID1、4、5、6などです。RAID0は、必要な冗長データがないため、不整合の問題の影響を受けません。アレイの異なるディスク間で同期されます。
RAIDアレイの不整合の問題に対処するには、いくつかの可能な戦略があります。
Linux MDソフトウェアRAIDは、デフォルトで、「ダーティ」とマークされたRAIDアレイを組み立てるときに「同期」戦略を使用します。つまり、RAID 1アレイの場合、ディスクの1つがマスターとして扱われ、そのデータが他のディスクにコピーされます。 RAID 4/5/6の場合、データブロックが読み取られます。次に、パリティブロックが再生成され、ディスクに書き込まれます。同期プロセスは非常に長くなる可能性があります。はるかに高速にするために、配列のホットチャンクを追跡する書き込みを意図した「ビットマップ」と呼ばれる機能があります。このビットマップ機能は、書き込み操作中のパフォーマンスの低下と引き換えに、同期プロセスの期間を大幅に短縮します。
バッテリバックアップメモリを備えたハードウェアRAIDアレイは、2ステップの戦略を使用します。最初に、書き込まれるデータブロックは、ジャーナルとして機能するメモリにコミットされます。この手順の後、データブロックがディスクに送信されます。停電イベントまたはその他の障害が発生した場合、RAIDコントローラーは、メモリ内のすべてのデータブロックが実際にディスクにコミットされていることを確認します。
CoW（コピーオンライト）戦略もあります。これについては、後で詳しく説明します。
「書き込みホール」の他の可能な定義は、特定の状況下でのRAID 4/5/6のデータ損失の問題を指します（RAIDレベル1および10は、この種の「書き込みホール」の影響を受けません）。私は問題の問題の ニール・ブラウンの定義 を引用しています：
"書き込みホールは、RAID4、RAID5、RAID6などのストライプ+パリティRAIDレイアウトに適用される単純な概念です。問題は、アレイが不適切なシャットダウンすべてのデバイスが使用できない場合、またはクリーンでないシャットダウン後にパリティが復元される前に読み取りエラーが検出された場合。」
つまり、たとえば、RAID 5アレイがあり、停電イベントが発生しています。 RAIDは、アレイを一貫した状態にしようとします。しかし、ディスクの1つが機能しないか、一部のセクターが読み取れません。したがって、一部が欠落しているため、データブロックからパリティを再生成することはできません。あなたは言うことができます：はい、しかし私たちはアレイに冗長性を持っています。したがって、パリティを使用して、欠落しているデータブロックを再生成できますか？答えはいいえだ。これを行うと、一部のデータブロックで不要なデータが取得される可能性があります。これは非常に深刻な問題です。一部のデータブロックが書き込まれたかどうかではありません（最新のジャーナルファイルシステムには、これに関する実際の問題はありません）。配列の一部のデータブロックが失われたか、または（再生成された場合）ガベージです。いずれにせよ、ここには深刻な問題があります。
この「書き込み穴」のより厳密な定義を採用すると、それは特殊なコーナーケースであり、特定の状況でのみ発生します。停電などの重大な障害が発生している必要があります。さらに、一部のディスクは（完全または部分的に）故障する必要があります。ただし、RAID 4/5/6（パリティブロックのレベル）の場合、リスクがあります。
このリスクは、2ステップの書き込み戦略（または以前に説明したジャーナルテクニックを使用した書き込み）を使用することで防止できます。ジャーナルの助けを借りて、すべてのデータブロックをディスクに安全に書き込むことができます。バッテリバックアップ式バッテリを備えたハードウェアRAIDは、適切に実装されていれば、「書き込みホール」の問題の影響を受けません。 Linux MDソフトウェアRAIDも ジャーナル機能を使用した書き込み を数年前に取得し、「書き込みホール」の問題を効果的に防止します。
ZFSについてはあまり詳しくありませんが、RAID-ZアレイではCoW（コピーオンライト）技術を使用して「書き込みホール」の問題を回避していると思います。すべてのデータとパリティを未使用のスペースに書き込み、次にこれらの物理ブロックへの仮想参照を更新します。この2ステップのプロセスを使用することにより、書き込み操作はアトミックであることが保証されます。書き込みホールの問題が効果的に防止されるように。
用語write holeは、バッテリーで保護されていないRAIDアレイを処理するときに発生する、似ているが異なる2つの問題を説明するために使用されるものです。
不適切anyと定義されている場合があります突然の電源喪失によるRAIDアレイの破損。この（誤った）定義では、2つの異なるディスクにアトミックに書き込むことができないため、RAID1は書き込みホールに対して脆弱です。
write holeの適切な定義、つまり全体のストライプストライプの更新中の突然の電源喪失によるデータ冗長性の喪失ですパリティベースのRAIDにのみ適用されます。
2番目の正しい書き込みホールの定義には、さらに説明が必要です。64Kのチャンクサイズと128Kのストライプサイズ（各ストライプの+ 64Kのパリティサイズ）を備えた3ディスクRAID5を想定します。ディスク＃1に4Kを書き込んだ後に電源が失われたが、ディスク＃3でduringパリティ更新を行った場合、偽の（つまり、破損した）パリティチャンクと、検出されないデータ整合性の問題が発生する可能性があります。後でディスク＃2が停止し、パリティを使用してディスク＃1とディスク＃3をXORすることで元のデータを回復した場合、再構築された64Kは元々ディスク＃2にあり、最近書き込まれたnotが書き込まれます。それにもかかわらず、破損している。
これは不自然な例ですが、write holeに関連する主な問題を明らかにする必要があります：同じものを共有する手つかずの、保管されていない、関連のないデータの損失最新の中断された書き込みでストライプ化します。言い換えると、fileAが何年も前に書き込まれたものの、書き込まれたばかりのfileBと同じストライプを共有し、fileBの更新中にシステムの電源が失われた場合、fileAが危険にさらされます。
考慮すべきもう1つのことは、アレイの書き込みポリシーです。読み取り/再構築/書き込み（つまり、部分的な書き込みが発生するとストライプ全体が再書き込みされます）と読み取り/変更/書き込み（つまり、影響を受けるチャンクとパリティのみが更新されます）を使用します。別の種類の書き込み穴。
上記から、RAID0とRAID1は適切な書き込みホールに悩まされていないため、明らかであるはずです。これらにはパリティーがなく、「非同期」でストライプ全体を無効にすることができます。 RAID1ミラーレッグcanは、正常にシャットダウンされなかった後は非同期になりますが、最新の書き込みデータのみが破損することに注意してください。以前に書き込まれたデータ（つまり、保存されているデータ）は問題に直面しません。
適切な書き込みホールを定義して範囲を指定した後、どのようにして回避できますか？
HW RAIDは、不揮発性書き込みキャッシュ（つまり、BBU + DRAMまたはコンデンサー付きのフラッシュモジュール）を使用して、書き込まれる更新を永続的に保存します。電源が失われた場合、電源が回復してシステムが起動すると、HW RAIDカードは保留中の操作を再発行し、キャッシュをディスクプラッターにフラッシュします。これにより、適切な書き込みホールだけでなく、最後に書き込まれたデータの破損からも保護されます。
Linux MD RAIDは、書き込むビットマップを記録する書き込みビットマップを使用しますbeforeそれらを更新します。電源が切れた場合、ダーティビットマップを使用して、影響を受けるストライプのパリティデータを再計算します。これは実際の書き込みホールのみから保護します。 （fsync（）+ writeバリアによってサポートされていない限り）書き込まれた最新のデータが破損する可能性があります。同じ方法を使用して、RAID1アレイの非同期の部分を再同期します（2つのミラーレッグが同期していることを確認するために、ミラーの書き込みホールが存在しない場合）。
新しいLinux MD RAID5/6にはlogging/journal deviceを使用するオプションが必要です。適切なHW RAIDカードの不揮発性ライトバックキャッシュを部分的にシミュレートします（特定のパッチ/実装によっては保護します）書き込みホールと最後に書き込まれたデータ破損の両方から、または書き込みホールのみから）;
最後に、RAIDZはboth書き込みホールと最後のデータ破損を最も「エレガント」であるがパフォーマンスに影響を与える方法を使用して回避します。フルサイズのストライプのみを書き込み（ZIL /での同期書き込みをジャーナリングする） SLOG）。
役立つリンク：
https://neil.brown.name/blog/20110614101708
https://www.kernel.org/doc/Documentation/md/raid5-ppl.txt
https://www.kernel.org/doc/Documentation/md/raid5-cache.txt
https://lwn.net/Articles/665299/