変更中に fallocate --dig-holes を使用するのは安全ですか?

Question

それは...ですか安全fallocate --dig-holes変更中/書き込み中のファイルに使用するには? たとえば、KVM ゲストによって開かれた QCOW2 イメージではどうでしょうか?

Answer 1

一般的には、いいえと答えます。ファイルが VM にマウントされたイメージである場合は、代わりに TRIM (例: fstrim -a) を試すことができます。厳密に言えば、これは同等ではありません (TRIM は、ゼロ化されていない削除されたファイルの領域を解放することもできます) が、これが必要な場合があります。

特定のケースでは安全かもしれませんが、それに頼ることはお勧めしません。たとえば、いくつかのデータがファイルに順番にストリーミングされる場合事前割り当てなしで、それは潜在的に安全であるように思えます。しかし、これはドキュメントで暗示されておらず、実装のみに依存するため、強くお勧めしません。

何が問題になるのでしょうか? アプリ/VM がゼロ化されたブロックを上書きし、同時に fallocate -d を実行するとします。競合は次のようになります。

1. Fallocate はゼロのブロックを見つけたので、そこに穴を掘ることに決めました。
2. 別のアプリケーション/VM がゼロ化されたブロックにデータを書き込みます。
3. ファロケートはブロックに穴を掘ります。

1 と 3 の間には短い時間枠があるように聞こえるかもしれません。それは本当かもしれませんが、fallocate は後続の複数のブロックを一度に解放する必要があるかもしれません。(実装を確認していないのでわかりませんが、たとえその逆が真実だとしても、将来的にそれに頼ることはできません。) これにより、1 と 3 の間の遅延が長くなり、競合状態が発生する可能性が高くなります。