ext4 中每个目录的最大文件数

Question

我管理一个包含文件存储的应用程序，其中所有文件都以等于其 md5 总和的文件名存储。所有文件都存储在一个目录中。目前有数千个文件，但很快就会在服务器上达到数百万个文件。当前服务器在 ext4 文件系统上运行 Ubuntu 11.10。

有人告诉我，将多个文件放在一个目录中是不明智的，因为这会显着增加查找时间和可靠性（他有一个关于单个目录可以指向的最大文件数的故事，从而导致一个很大的链表）。相反，他建议使用例如文件名的子字符串创建子目录。但是，这会使我的应用程序中的某些事情变得更加麻烦。

这仍然是真的，还是现代文件系统（例如 ext4）有更有效的方法来处理这个问题并自然扩展？维基百科有一些关于文件系统的详细信息，但它并没有真正说明每个目录的最大文件数或查找时间。

Answer 1

在ext3后来的文件系统支持散列B树的目录索引。只要您执行的唯一操作是按名称添加、删除和访问，这就会很好地扩展。但是，我仍然建议分解目录。否则，您会为在目录上执行其他操作的工具（updatedb、ls、du等）创建一个危险的陷阱，如果目录中有太多条目，这些操作可能会爆炸。

Answer 2

问题的核心是在目录 inode 中挖掘您想要的一个文件。一些文件系统比其他文件系统做得更好。一些规模接近数十亿，但如果你只有...... 20K 文件访问这些文件的速度明显更快。此外，大文件数会给某些工具带来问题，并因此可能使备份/恢复成为一个更加困难的问题。

碰巧我在我们自己的开发中遇到了完全相同的问题（md5sum 作为文件名，其缩放）。我向我们的开发人员推荐的是将字符串切成碎片。他们以 4 组为一组，但在我们当时使用的文件系统上，即使从性能角度来看，许多文件系统也会证明存在问题，因此他们最终将前 6 个三元组拆分为 3 组，其余为终端目录中的文件名。

4 人一组：4976/d70b/180c/6142/c617/d0c8/9d0b/bd2b.txt
3 人一组：497/6d7/0b1/80c/614/2c6/17d0c89d0bbd2b.txt

这具有保持目录大小较小的优点，并且由于 MD5sum 非常随机，它将创建平衡的目录树。最后一个目录不太可能获得多个文件。并且在我们的代码中工作并不难。我们处理数百万个文件项目，因此扩展对我们来说非常重要。

Answer 3

现代文件系统可以很好地处理非常大的目录，甚至可以处理数百万个文件。但传统工具则不然。例如，用“ls”列出这么大的目录需要很长时间，因为它通常会读取整个目录并对其进行排序（尽管您可以使用 ls -f 来避免排序）。在读取所有文件之前，它不会开始显示文件。拆分名称在某些情况下有帮助，但并非全部（例如 rsync 复制可能仍需要收集整个名称树）。