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）で記述された変更に従って更新します。
- ハードウェアにデータをディスクにフラッシュするように依頼します-ハードウェアはすべての保留中のデータを書き込みます。
- ヘッドポインタを新しいマークルツリーに更新します。
- 不要になった古いブロックを解放します。
（4）後に電源が失われた場合、トランザクションは完了します。手順（1）から（3）の間に電源が失われると、ファイルシステムは古い状態になります（手順（1）で書き込まれたデータは失われますが、ファイルシステムは一貫しています）。ファイルシステムエラーをチェックする必要がないことに注意してください。これは、ファイルシステムがすぐに利用可能になることを意味します。これは大きな利点です（大きなファイルシステムのチェックには非常に時間がかかる場合があります）。
これは、「バギー」ハードウェアで問題が発生する可能性のある例です。
- ディスク上の空きブロックにデータを書き込みます。
- マークルツリー*のコピーを作成し、（1）で記述された変更に従って更新します。
- ハードウェアにデータをディスクにフラッシュするように依頼します-ハードウェアは完了を確認しますが、完全にはフラッシュしません（たとえば、データがディスクのライトバックキャッシュに残っている可能性があります）。
- ヘッドポインタを新しいマークルツリーに更新します。このデータは、他の保留中のデータよりも先にディスクに書き込まれます（たとえば、ディスクのヘッドが正しい場所にあるため）。
- 手順（1）と（2）で書き込んだデータをディスクに書き込みます。
- 不要になった古いブロックを解放します。
（4）と（5）の間で電源が失われた場合、または手順（5）の実行中にファイルシステムが不整合になります。その結果、マークルツリーやデータが部分的にしか書き込まれず、ファイルシステムが不整合になる可能性があります。
実際には、RAIDコントローラーを使用する場合は特に注意する必要があります 。通常は、ディスク上のライトバックキャッシュを無効にし、代わりに独自のライトバックキャッシュを使用します。ここで問題が発生する一般的な方法は2つあります。
- RAIDコントローラーのキャッシュはRAMです。 バッテリーまたは同様のテクノロジーに支えられていない場合、大量のデータが失われる可能性があります。
- 一部のディスクは、要求されたときにライトバックキャッシュを無効にしません 。これは、RAID用に設計されたサーバードライブよりも安価なデスクトップドライブで発生する可能性が高くなります。
*ここでは簡略化しています。実際には、ツリー全体をコピーする必要はありません。 変更された部分のみを追加する必要があります-残りの部分は古いツリーと新しいツリーの間で共有できます 。