BTRFSは停電時のデータの一貫性を保証しますか？

ZFSは、排他的に述べて、ZFSは無傷であると主張されています ZFSは、電源障害に対して脆弱である可能性があることを受け入れます。

BTRFSについてのそのようなステートメントは見つかりませんでした。停電の間に耐久性がありますか（または設計されている/計画されています）？

#btrfs IRCで質問しましたshould be ok if your hw isn't "buggy"が、「バギーでない」とはどこを意味するのでしょうかyour hw has correct flush/barrier semantics。

TL; DR：これは、btrfsがZFSと同様の方法で停電によるデータ破損から保護されることを意味します。

理由は次のとおりです。ZFSとbtrfsの背後にある一般的な考え方は似ています。どちらもデータ構造としてマークルツリーを使用します。書き込みでは、ディスク上の複数のブロックを更新する必要がある場合があります。ファイルシステムはこれを処理し、新しいデータを空のブロックに書き込み（既存のファイルが変更されている場合でも、古い状態を反映するブロックを変更する必要はありません）、新しく更新されたツリーを構築します。すべての重い作業が完了し、データ+更新されたツリーがディスクに書き込まれると、ヘッドポインタが新しいツリーに更新され、変更が表示されます。

以下は、ファイルへの書き込み時に想定される動作です。

1. ディスク上の空きブロックにデータを書き込みます。
2. マークルツリー*のコピーを作成し、（1）で書かれた変更に従って更新します。
3. ハードウェアにデータをディスクにフラッシュするように依頼します-ハードウェアは保留中のすべてのデータを書き込みます。
4. ヘッドポインタを新しいマークルツリーに更新します。
5. 不要になった古いブロックを解放します。

（4）の後で電源が失われた場合、トランザクションは完了します。手順（1）から（3）の間に電源が失われた場合、ファイルシステムは古い状態になります（手順（1）で書き込まれたデータは失われますが、ファイルシステムは一貫しています）。ファイルシステムエラーをチェックする必要がないことに注意してください。これは、ファイルシステムがすぐに使用できることを意味します。これは大きな利点です（大きなファイルシステムのチェックには非常に時間がかかることがあります）。

「バギー」ハードウェアで問題が発生する例を次に示します。

1. ディスク上の空きブロックにデータを書き込みます。
2. マークルツリー*のコピーを作成し、（1）で書かれた変更に従って更新します。
3. ハードウェアにデータをディスクにフラッシュするように依頼します-ハードウェアは完了を確認しますが、完全にはフラッシュしません（たとえば、データがディスクのライトバックキャッシュに残っている可能性があります）。
4. ヘッドポインタを新しいマークルツリーに更新します。このデータは、他の保留中のデータの前にディスクに書き込まれます（たとえば、ディスクのヘッドがたまたま正しい場所にあるため）。
5. 手順（1）および（2）で書き込まれたデータは、ディスクに書き込まれます。
6. 不要になった古いブロックを解放します。

（4）と（5）の間、または手順（5）の実行中に電源が失われた場合、ファイルシステムは不整合になります。その結果、マークルツリーやデータが部分的にしか書き込まれず、ファイルシステムの不整合が発生する可能性があります。

実際には、RAIDコントローラーを使用する場合は特に注意が必要です。通常は、ディスク上のライトバックキャッシュを無効にし、代わりに独自のライトバックキャッシュを使用します。ここで問題が発生する一般的な方法は2つあります。

• RAIDコントローラのキャッシュはRAMです。バッテリーや類似のテクノロジーでバックアップされていない場合、大量のデータが失われる可能性があります。
• 一部のディスクは、要求されたときにライトバックキャッシュを無効にしません。これは、RAID用に設計されたサーバードライブよりも安価なデスクトップドライブで発生する可能性が高くなります。

*ここでは簡略化しています。ツリー全体をコピーする必要は実際にはありません。追加する必要があるのは、変更された部分だけです。残りの部分は、古いツリーと新しいツリーの間で共有できます。