Linuxカーネル
最近明らかになったのは、 Linux 6.2カーネルに含めるためにBtrfsの改善が提案されました RAID 5/6 実装での書き込みホールの問題を修正します。
問題の本質は、記録中にクラッシュが発生した場合、どの RAID デバイスのどのブロックに正しく書き込まれ、どのブロックに記録が完了しなかったかを最初は理解できないという事実に要約されます。
この状況で RAID を再構築しようとすると、RAID ブロックの状態が同期していないため、サブスクライブされたブロックに対応するブロックが破損する可能性があります。 この問題は、この影響に対処するための特別な対策が講じられていない RAID1/5/6 アレイで発生します。
btrfs の RAID1 のような RAID 実装では、この問題は解決されます。 両方のコピーでチェックサムを使用することにより、不一致がある場合、データは XNUMX 番目のコピーから単純に復元されます。 このアプローチは、デバイスが完全に故障するのではなく、不良データを出し始めた場合にも機能します。
しかし、 RAID5/6 の場合、ファイル システムはチェックサムを保存しません。 パリティ ブロックの場合 - 通常の状況では、ブロックがすべてチェックサムを備えているという事実によってブロックの正確性がチェックされ、データからパリティ ブロックを再作成できます。 ただし、部分的な記録の場合、このアプローチは特定の状況で機能しない場合があります。 この場合、 アレイを復元するとき、 不完全なレコードに残されたブロック 正しく復元されません。
btrfs の場合、発生する書き込みがストライプよりも小さい場合、この問題はより重要になります。 この場合、ファイル システムは読み取り-変更-書き込み (RMW) 操作を実行する必要があります。
書き込み進行中のブロックが検出された場合、チェックサムに関係なく、RMW 操作によって破損が検出されない可能性があります。 開発者は、RMW 操作がこの操作を実行する前にブロックのチェックサムを検証し、必要に応じてデータ リカバリが書き込み後にチェックサム検証も実行するように変更を加えました。
残念ながら、不完全なフリンジ (RMW) が書き込まれる状況では、これによりチェックサムを計算するための追加のオーバーヘッドが発生しますが、信頼性が大幅に向上します。 RAID6 の場合、そのようなロジックはまだ準備ができていません。
さらに、開発者からの RAID5/6 の使用に関する推奨事項に注意することができます。その本質は、Btrfs ではメタデータとデータを格納するためのプロファイルが異なる可能性があることです。 この場合、メタデータには RAID1 (ミラー) または RAID1C3 (3 コピー) プロファイルを使用し、データには RAID5 または RAID6 を使用できます。
これにより、一方では信頼性の高いメタデータ保護と「書き込みホール」の不在が保証され、他方では RAID5/6 に典型的な、より効率的なスペースの使用が保証されます。 これにより、メタデータの破損が防止され、データの破損を修正できます。
さらに カーネル 6.2 の Btrfs 上の SSD の場合、 la 「破棄」操作の非同期実行 (物理的に保存できなくなった解放済みブロックをマークする) は、デフォルトでオンになります。
これのメリット モードはハイパフォーマンス キュー内の破棄操作の効率的なグループ化と、バックグラウンド ハンドラーによるキューの後処理により、通常の FS 操作は、ブロックが解放されるときに同期「破棄」の場合のように遅くなることはなく、SSD のパフォーマンスが向上します。決定。 一方、追加のスキャンを必要とせず、操作を遅くすることなく、使用可能なすべてのブロックが FS で消去されるため、fstrim などのユーティリティを使用する必要がなくなります。
最後に、あなたがそれについてもっと知ることができることに興味があるなら、あなたは詳細を調べることができます 次のリンク。