web-dev-qa-db-ja.com

エントリが削除された後、大量のエントリを持つディレクトリのサイズが縮小しないのはなぜですか？

投票終了通知：リンクされた複製は同じ質問をしますが、コメントと唯一の回答は信頼できる情報源から引き出される回答を提供しません。 Thomas Dickeyによる私の質問への回答 は、実際に私が求めていた答えを提供します。したがって、提案された複製は役に立ちませんが、ここでのトーマスの答えは適切です。

スーパーユーザーの質問に対するG-Manの回答 および個人アカウント このPerlDuckのコメント によると、大量のエントリを持つディレクトリは、4096バイトを超えるサイズになります（これにより、 ls -l output）、ただしエントリが削除されると-数が減ることはありません。

質問は「なぜ」ですか？それはext4ファイルシステムはディレクトリのメタデータを保持するように設定されていますか？ディレクトリを削除して再作成することは、元のiノードを削除して新しいiノードを作成するため、解決策ではありません。手動で数を減らすにはどうすればよいですか？

directoryext4inode
8
Sergiy Kolodyazhnyy

開発者を引用する （Linuxカーネルスレッドではext3/ext4ディレクトリは大量のファイルを削除しても縮小されません）：

On Thu, May 14, 2009 at 08:45:38PM -0400, Timo Sirainen wrote:
>
> I was rather thinking something that I could run while the system was  
> fully operational. Otherwise just moving the files to a temp directory +
> rmdir() + rename() would have been fine too.
>
> I just tested that xfs, jfs and reiserfs all shrink the directories  
> immediately. Is it more difficult to implement for ext* or has no one  
> else found this to be a problem?

It's probably fairest to say no one has thought it worth the effort.
It would require some fancy games to swap out block locations in the
extent trees (life would be easier with non-extent-using inodes), and
in the case of htree, we would have to keep track of the index block
so we could remove it from the htree index.  So it's all doable, if a
bit tricky in terms of the technical details; it's just that the
people who could do it have been busy enough with other things.

It's hasn't been considered high priority because most of the time
directories don't go from holding thousands of files down to a small
handful.  

                                                - Ted
11
Thomas Dickey