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

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

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

这是否仍然正确，或者现代文件系统（例如ext4）是否具有更有效的方式来处理此问题并自然扩展？维基百科上有一些有关文件系统的详细信息，但实际上并没有说每个目录的最大文件数或查找时间。

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

问题的核心是在目录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相当随机，因此它将创建平衡的目录树。最后一个目录不可能获得多个文件。编写我们的代码并不难。我们处理着数百万个文件项目，因此扩展对我们非常重要。

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

我可能建议改用SQL数据库吗？这可能会将您在应用程序中的这种弱点转化为优势。