Linuxファイルシステムは、ブロックが不要になったときにブロックデバイスに通知しますか？

Question

従来、ストレージデバイス（ハードドライブ）には、単にデータを上書きする以外にデータを「削除」するメカニズムがないと想定されていました。基本的なストレージが不要になったことをブロックデバイスに通知するのに役立つ理論的なシナリオがいくつかありますが、そのためのメカニズムはありません。

ユースケース：

最近のほとんどすべてのSSDは、寿命を延ばすために Wear Leveling を使用しています。これは、報告されているサイズよりも多くの内部ストレージのブロックを用意し、ブロック間を循環させることで達成できます。しかし、SSDにブロックが不要になったと通知された場合、循環するプールがはるかに大きくなります。
RAM（tmpfsを含まない）で作成されたファイルシステム。ファイルが削除されると、基になるramdiskは割り当てられたスペースを解放できませんRAMスペースが不要であることを報告しない。
zram を使用するようなスワップソリューションは、ページがスワップスペースで使用されなくなったときにブロックデバイスに通知する必要があります。そうしないと、RAMにかなりの量の「ジャンク」が残ります。

これは FALLOC_FL_PUNCH_HOLE 。しかし、私がそこで読むことができることから、それは純粋にファイルシステム内のファイルからスペースを割り当て解除するためのものです。つまり、ユーザースペースアプリケーションは、スペースが不要であることをファイルシステムに通知できます。しかし、それはファイルシステムがブロックデバイスにスペースが必要ないことを通知するのと同じではありませんまたはそれですか？

それでは、各シナリオで回避策があるのでしょうか、それとも、ブロックが不要になったときにファイルシステムとスワップがブロックデバイスに通知できるようにするメカニズムがありますか？

Stephen Kitt · Accepted Answer

Linuxでは、ファイルシステムは blkdev_issue_discard を使用して、1つ以上のブロックが不要になったことをブロックレイヤーに通知できます。実際には、ファイルシステムはこれを使用して、通常「破棄」オプションでファイルシステムをマウントすることにより、対応する動作が要求されたときにブロックを破棄します。中間層もこの要求を使用して、破棄を伝達します、たとえばMD層。

これはデフォルトでは行われません。 the ext4 manpage は、「十分なテストが完了するまで、デフォルトではオフになっている」と述べていますが、 TooTea を思い出して、多くのSSDはうまく処理できません定数は破棄されるため、代わりに定期的に fstrim を実行することをお勧めします。ほとんどのファイルシステムのデフォルトの動作は、対応するコンテンツが削除されたときに、内部でブロックに未使用のマークを付けることです。これにより、ファイルシステム固有の「削除取り消し」ユーティリティを使用しても、 PhotoRec などのブロックデバイス探索ツールを使用しても、誤って削除した後にファイルの内容を復元できます。さらに処理せずに未使用のブロックをマークすると、ファイルの削除をすばやく実行することもできます。

明示的な破棄がなければ、ブロックが不要になったときにファイルシステムがあまり処理を行わないという事実は、シンプロビジョニングに必要以上の作業が伴うことを意味しています。したがって、XenはExt3ファイルシステムのシンプロビジョニングに対する特定のサポートを備えています。ブロックレイヤーは、そこに格納されているファイルシステムについて「認識」し、それを利用して、ファイルシステムが明示的に何かを通知することなく、不要なブロックを識別します。 VMwareでは、シンプロビジョニング、または未使用のブロックを特定してシンプロビジョニングされたブロックデバイスのストレージ要件を削減するには、未使用のブロックをゼロにして分析ツールを実行する必要があります。 SANベースのシンプロビジョニングシステムでも同様のサポートがあります。（破棄サポートを使用すると、シンプロビジョニングがはるかに簡単になります。シンプロビジョニングされたボリュームはトリミングのサポートをアドバタイズし、残りはファイルシステムが行います。）

FALLOC_FL_PUNCH_HOLE は、説明したように、ファイルシステムレベルの操作ですが、基盤となるファイルシステムがそれをサポートし、適切な破棄オプションを使用してマウントすると、ブロックが破棄されます。