Btrfs の改善は、RAID 6.2/5 実装における書き込みホールの問題を解決するために、Linux 6 カーネルに組み込むことが提案されています。 問題の本質は、記録中にクラッシュが発生した場合、どの RAID デバイスのどのブロックが正しく書き込まれたのか、また記録が完了しなかったのかを最初は理解できないという事実に帰着します。 この状況で RAID を復元しようとすると、RAID ブロックの状態が同期していないため、アンダーライトされたブロックに対応するブロックが破壊される可能性があります。 この問題は、この影響に対処するための特別な対策が講じられていない RAID1/5/6 アレイで発生します。
btrfs の RAID1 などの RAID 実装では、この問題は両方のコピーのチェックサムを使用することで解決され、不一致がある場合はデータが XNUMX 番目のコピーから復元されます。 このアプローチは、一部のデバイスが完全な障害ではなく、誤ったデータを送信し始めた場合にも機能します。
ただし、RAID5/6 の場合、ファイル システムはパリティ ブロックのチェックサムを保存しません。通常の状況では、ブロックの有効性はすべてのチェックサムが測定されることによって検証され、パリティ ブロックを再構築できます。データから。 ただし、部分的な録音の場合、状況によってはこのアプローチが機能しない場合があります。 この場合、配列を復元するときに、不完全なレコードに該当するブロックが誤って復元される可能性があります。
btrfs の場合、この問題は、生成されるレコードがストライプよりも小さい場合に最も関係します。 この場合、ファイル システムは読み取り-変更-書き込み操作 (読み取り-変更-書き込み、RMW) を実行する必要があります。 これにより、書き込みが不完全なブロックが発生した場合、RMW 操作により、チェックサムに関係なく、検出できない破損が発生する可能性があります。 開発者は、RMW 操作がこの操作を実行する前にブロックのチェックサムをチェックし、データを復元する必要がある場合は記録後にチェックサムもチェックするように変更を加えました。 残念ながら、不完全なストライプ (RMW) を書き込む状況では、チェックサムを計算するための追加のオーバーヘッドが発生しますが、信頼性は大幅に向上します。 RAID6 の場合、そのようなロジックはまだ準備ができていませんが、RAID6 でのこのような障害の場合は、2 つのデバイスで同時に書き込みが失敗する必要がありますが、その可能性は低くなります。
さらに、開発者からの RAID5/6 の使用に関する推奨事項にも注目できます。その本質は、Btrfs ではメタデータとデータ ストレージ プロファイルが異なる可能性があるという事実に要約されます。 この場合、メタデータにはプロファイル RAID1 (ミラー) または RAID1C3 (3 コピー) を使用し、データには RAID5 または RAID6 を使用できます。 これにより、信頼性の高いメタデータ保護と「書き込みホール」の不在が保証される一方で、RAID5/6 の特徴であるスペースのより効率的な使用が保証されます。 これにより、メタデータの破損を回避し、データの破損を修正できます。
カーネル 6.2 の Btrfs の SSD では、「破棄」操作の非同期実行がデフォルトでアクティブ化されることにも注意してください (物理的に保存する必要がなくなった解放されたブロックにマークを付けます)。 このモードの利点は、キュー内の「破棄」操作が効果的にグループ化され、バックグラウンド プロセッサによってキューがさらに処理されるため、パフォーマンスが高いことです。そのため、同期の場合のように、通常の FS 操作が遅くなることがありません。ブロックが解放されると、SSD はより適切な決定を下せるようになります。 一方、追加のスキャンを必要とせず、操作を遅くすることなく、使用可能なすべてのブロックが FS でクリアされるため、fstrim などのユーティリティを使用する必要はなくなります。
出所： オープンネット.ru