そうでない場合、それを書くことはどれほど実現可能でしょうか? 各ディレクトリのコンテンツのサイズを再帰的に保持し、ファイルシステムの変更ごとにサイズを再計算するのではなく、たとえばファイルが削除または拡大されたときにディレクトリのサイズを更新することによって更新されるファイルシステム。
2 に答える
私はそのようなファイルシステムを知りません。ファイルシステムの観点からは、ディレクトリはファイルです。
以下を使用できます。
du -s -h <dir>
ディレクトリ内のすべてのファイルの合計サイズを表示します。
ファイルシステムの観点からは、ディレクトリのサイズはその存在に関する情報のサイズであり、メディアに物理的に保存する必要があります。合計10GBのファイルを含むディレクトリの「サイズ」は、実際には空のディレクトリの「サイズ」と同じになることに注意してください。これは、その存在をマークするために必要な情報が同じストレージスペースを必要とするためです。そのため、ファイル (ソケット、リンク、および内部のその他のもの) のサイズは、実際には「ディレクトリ サイズ」と同じではありません。サブディレクトリは、リモートや再帰的にマウントするなど、さまざまな場所からマウントできます。実際のファイルは物理的にディレクトリの「内部」にあるわけではないため、ある程度のディレクトリ サイズは人間の視覚にすぎません。ディレクトリは単なるコンテナのマークであり、特別なファイル (デバイス ファイルなど) が特別なファイルとしてマークされるのとまったく同じ方法です。ディレクトリの合計サイズの再計算と更新は、サイズの合計よりもその中のアイテムの数に依存します。最新のファイルシステムは、サブディレクトリがなくても、1 つのディレクトリに「」数十万のファイル (それ以上ではないにしても) を保持できるため、それらのサイズを数えます。この情報を持つことで得られる可能性がある利益と比較して、非常に重い作業になる可能性があります。要するに、たとえば "du" (ディスク使用量) コマンドを実行するとき、または Windows でディレクトリ サイズをカウントするとき、ファイルシステム ドライバーを使用してカーネルで実際に何らかの方法でそれを実行しても速くはなりません - カウントはカウントです。この情報を持つことで得られる可能性のある利益と比較して。要するに、たとえば "du" (ディスク使用量) コマンドを実行するとき、または Windows でディレクトリ サイズをカウントするとき、ファイルシステム ドライバーを使用してカーネルで実際に何らかの方法でそれを実行しても速くはなりません - カウントはカウントです。この情報を持つことで得られる可能性のある利益と比較して。要するに、たとえば "du" (ディスク使用量) コマンドを実行するとき、または Windows でディレクトリ サイズをカウントするとき、ファイルシステム ドライバーを使用してカーネルで実際に何らかの方法でそれを実行しても速くはなりません - カウントはカウントです。
特定のユーザーまたはグループが所有するファイルの合計サイズに関する情報を保持および更新するクォータ システムがあります。さらに、あなたが言ったように、ファイルが大きくなったり削除されたりすると、クォータの使用状況が更新されます。そのため、情報が不正確になる可能性があります.最初から」、それが有効になっているパーティションで。
また、IO 操作速度 (ファイルに関する情報の読み取りを含む) のボトルネックは、通常、メディア自体の速度、通信バス、CPU の速度であることに注意してください。ただし、すべてのファイルシステムは RAM FS と同じくらい高速であると考えています。RAM FS はおそらく最も単純なファイル システムであり、実質的に RAM に保持されるため、IO 操作が非常に高速になります。モジュールでビルドして、説明した機能を追加してみてください。多くの興味深いことを学ぶことができます:)
FUSE は「ユーザー空間のファイル システム」の略で、Fuse で実装された FS は通常非常に低速です。特定の場合の機能が速度よりも重要な場合、それらは理にかなっています。たとえば、USB 経由でコンピュータに接続された、新しく購入した電子温度計から読み取った温度に基づいて疑似ファイルシステムを作成できますが、それらは速度デーモンではありません。知る :)