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

— 永远循环
source

不太确定为什么不赞成这样做。这些是合法的，明确表达的问题，带有用于复制场景的命令。这些问题的答案将使社区知识满意，并且在某个地方进行记录会很有用。

— loopforever 2011年

9

以下是ext2 / ext3 / ext4的正确答案。对于其他文件系统，它们是否成立取决于它们的实现。

user48838正确回答了这个问题。更多文件消耗更多元数据。它们以4k块或文件系统创建时定义的任何其他大小分配
是的，这是真实文件系统的功能/问题
在ext3文件系统中，这是不可能的。仅通过重新创建（空）目录
源代码在这里和相关文件中

但是你很幸运。当您重新创建已删除的文件数量时，目录大小将保持不变。仅当您添加更多文件时，它才会增加。

— 邮件
source

1

一件事：“ e2fsck -fD”应该压缩ext2 / 3文件系统中的每个目录。尽管我怀疑它很慢，并且文件系统必须处于脱机状态，但这可能会满足OP的要求。这可能比链接新目录中的每个文件并删除旧目录所花费的时间更长。

— 2011年

4

您看到的块增加是由于文件系统如何管理其文件存储以及相关的文件管理信息。在您描述的情况下，这似乎以4K为增量，因此，无论实际数据大小是否填满整个4K，文件系统中的每个“新” /“唯一”条目都将保留4K。如果相关数据占用了整个4K，则需要保留另一个4K块并填充它，以存储整个相关数据流/序列。

根据文件系统管理的“硬”删除还是“软”删除，删除可能不会（通常不是为了“取消删除”功能）立即释放保留的块。某些文件系统可能会区分不同类型的“删除”，并提供相应的存储块管理功能。

文件系统对存储管理的实现方式和实现方式各不相同，因此在支持多个/模块化文件系统的OS中，该OS通常只会为文件系统集成提供“挂钩”。

— 用户名
source

1

在user48838的正确答案中添加了一些混乱的评论：

一切都是文件，包括目录。要存储所有文件信息，您需要空间。

例如，在一个小目录中显示“ 64B used”并实际显示已使用的空间量也是有效的，但是无论如何我们都会在磁盘上使用4K的倍数，因此，仅显示已用空间量。

从FS设计的角度来看，您为什么要麻烦计算使用的内容呢？没有必要。然后，您必须移动条目以避免留下漏洞……舔。

当发生删除操作且目录大小减小从而可以释放一个块时，所有管理工作都需要进行，然后才能实际执行。为什么要节省几个KB？奇怪的是，无论如何您以后都必须扩展它。

留给读者练习：考虑一下为什么将/ lost + found目录创建为空但占用16K的空间（至少在ext3上）。

— 米奇
source