web-dev-qa-db-ja.com

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

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の機能ですか？
  • ディレクトリを削除して再作成せずに、ディレクトリサイズを縮小することはできますか？
  • ボーナスポイント：この動作が実装されているカーネルソースコードを教えてください。
linuxinodevfs
8
loopforever

Ext2/ext3/ext4に当てはまる答えは次のとおりです。それらが他のファイルシステムに当てはまるかどうかは、それらの実装によって異なります。

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

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

9
mailq

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

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

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

4
user48838

User48838の良い答えにいくつかのとりとめのない解説を追加します。

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

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

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

削除が発生し、ディレクトリサイズが減少して、couldがブロックを解放できる場合、実際に実行する前に、すべての管理を実行する必要があります。なぜわざわざ数KBを節約するのですか？とにかく後で拡張する必要がある可能性があります。

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

1
MikeyB