Linuxディレクトリサイズ/ブロック数の単調増加

8

Linuxでは（おそらくファイルシステムのブロックサイズの関数として）、ディレクトリを作成するとstat、4096のサイズが返されます。このディレクトリに、ある程度のサイズのファイルを作成できます。ディレクトリ（から報告stat）。

ある時点で、ディレクトリが多くのファイルでいっぱいになると、ディレクトリのサイズが膨らみます（ディレクトリの内容について話しているのではなく、ディレクトリ自体を表すために消費されるブロックについて話している）。ファイルを削除しても、ディレクトリのサイズは変わりません。

ここに簡単な例があります：

[root@uxlabtest:/]$ mkdir test
[root@uxlabtest:/]$ stat test
  File: `test'
  Size: 4096            Blocks: 8          IO Block: 4096   directory
Device: fd00h/64768d    Inode: 1396685     Links: 2
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2011-07-26 14:06:04.000000000 -0400
Modify: 2011-07-26 14:06:04.000000000 -0400
Change: 2011-07-26 14:06:04.000000000 -0400

次に、一連のファイルをタップします。

[root@uxlabtest:/]$ for i in `seq 1 10000`; do touch /test/$i; done
[root@uxlabtest:/]$ stat test
  File: `test'
  Size: 155648          Blocks: 312        IO Block: 4096   directory
Device: fd00h/64768d    Inode: 1396685     Links: 2
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2011-07-26 14:06:04.000000000 -0400
Modify: 2011-07-26 14:06:56.000000000 -0400
Change: 2011-07-26 14:06:56.000000000 -0400

次に、ファイルを削除します。

[root@uxlabtest:/]$ rm -rf /test/*
[root@uxlabtest:/]$ stat test
  File: `test'
  Size: 155648          Blocks: 312        IO Block: 4096   directory
Device: fd00h/64768d    Inode: 1396685     Links: 2
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2011-07-26 14:07:11.000000000 -0400
Modify: 2011-07-26 14:07:12.000000000 -0400
Change: 2011-07-26 14:07:12.000000000 -0400

私の質問は：

ディレクトリのサイズ/ブロック数が単調に増加するのはなぜですか？
これは、基盤となるファイルシステムまたはLinux VFSの機能ですか？
ディレクトリを削除して再作成することなく、ディレクトリのサイズを縮小できますか？
ボーナスポイント：この動作が実装されているカーネルソースコードを教えてください。

linux inode vfs

— 永遠にループする
ソース

なぜこれが反対投票されたのか本当にわからない。これらは、シナリオを複製するために与えられたコマンドを使用して、正当で明確に表現された質問です。これらの質問への回答は、コミュニティの知識を満たし、どこかに文書化しておくと役立ちます。

— 永久にループする

9

ext2 / ext3 / ext4に当てはまる答えを次に示します。それらが他のファイルシステムに当てはまるかどうかは、その実装に依存します。

user48838がこれに正しく答えました。より多くのファイルはより多くのメタデータを消費します。ファイルシステムの作成時に定義された4kチャンクまたはその他のサイズで割り当てられます。
はい、それは実際のファイルシステムの機能/問題です
ext3ファイルシステムでは、これは不可能です。（空の）ディレクトリを再作成することによってのみ
ソースコードはここと関連ファイルにあります

しかし、あなたには運があります。すでに削除したファイルと同じ量を再作成すると、ディレクトリサイズは同じままです。ファイルを追加した場合にのみ、ファイルは増加します。

— mailq
ソース

1

1つのこと：「e2fsck -fD」はext2 / 3ファイルシステムのすべてのディレクトリを圧縮する必要があります。これは、OPが望むことを実行する可能性がありますが、遅いと思われ、ファイルシステムはオフラインである必要があります。これはおそらく、新しいディレクトリ内のすべてのファイルをリンクして古いファイルを削除するよりも時間がかかります。

— akramer

4

表示されているブロックの増分は、ファイルシステムがファイルのストレージと関連するファイル管理情報を管理する方法が原因です。説明した状況では、4Kの増分で表示されるため、実際のデータサイズが4K全体を占めるかどうかに関係なく、ファイルシステムへの各「新規」/「一意」のエントリは4Kを予約します。関連データが4K全体を占める場合、関連するデータストリーム/シーケンス全体を格納するために、必要に応じて別の4Kブロックが予約され、埋められます。

ファイルシステムによって管理される「ハード」削除と「ソフト」削除によっては、削除しても予約されたブロックがすぐに解放されない場合があります（通常、「削除解除」機能は対象外）。一部のファイルシステムは、さまざまなタイプの「削除」を区別し、対応するストレージブロック管理機能を提供します。

ストレージ管理へのアプローチと実装の方法はファイルシステムによって異なるため、複数/モジュールファイルシステムをサポートするOSでは、OSは通常、ファイルシステムを統合するための「フック」のみを提供します。

— user48838
ソース

1

user48838の良い答えにいくつかのとりとめのないコメントを追加します。

ディレクトリを含むすべてがファイルです。そのすべてのファイル情報を格納するには、スペースが必要です。

小さなディレクトリに対して「64B used」を表示して実際に使用されたスペースの量を表示することも有効ですが、とにかくディスク上で4Kの倍数を使用しているので、単に使用済みスペースの量。

FS設計の観点から、使用されたものを計算する問題に悩む必要があるのはなぜですか？必要はありません。そして、穴を残さないようにエントリを移動する必要があります。

削除が発生し、ブロックサイズを解放できるようにdirサイズが低下した場合、実際に解放する前に、すべての管理を実行する必要があります。なぜ数KBを節約する必要があるのですか？おそらく、とにかく後でそれを拡張する必要があるでしょう。

読者のための演習として残しました。/lost+foundディレクトリが空で作成されているが、16Kを占める理由を考えてください（少なくともext3では）。

— MikeyB
ソース