Ext3实际上有目录大小限制，它们取决于文件系统的块大小。没有每个目录的文件“最大数量”，而是每个目录的“用于存储文件条目的最大块数量”。具体来说，目录本身的大小不能超过高度为3的b-树，并且树的扇出取决于块大小。有关详细信息，请参见此链接。

https://www.mail-archive.com/cwelug@googlegroups.com/msg01944.html

我最近在一个格式化为2K块的文件系统上就遇到过这种情况，它莫名其妙地得到目录已满的内核消息警告:ext3_dx_add_entry:目录索引已满!当我从另一个ext3文件系统复制时。在我的例子中，一个只有480,000个文件的目录无法复制到目标。

这完全取决于文件系统。许多现代文件系统使用良好的数据结构来存储目录的内容，但旧的文件系统通常只是将条目添加到列表中，因此检索文件是一个O(n)操作。

即使文件系统做得正确，列出目录内容的程序仍然绝对有可能搞砸并执行O(n^2)排序，因此为了安全起见，我总是将每个目录的文件数量限制在不超过500个。

这实际上取决于所使用的文件系统，以及一些标志。

例如，ext3可以有数千个文件;但在几千次之后，它就变得非常缓慢了。主要是在列出目录时，但也在打开单个文件时。几年前，它获得了“htree”选项，这极大地缩短了给定文件名获取inode所需的时间。

就我个人而言，我使用子目录将大多数级别保持在1000个左右的项目以下。在您的例子中，我将创建256个目录，使用ID的最后两个十六进制数字。使用最后一个数字，而不是第一个数字，这样可以实现负载平衡。

这在一定程度上取决于Linux服务器上使用的特定文件系统。现在默认是ext3和dir_index，这使得搜索大目录非常快。

所以速度不应该是一个问题，除了你已经注意到的问题，那就是上市需要更长的时间。

一个目录下的文件总数是有限制的。我记得它可以运行到32000个文件。

Ext3实际上有目录大小限制，它们取决于文件系统的块大小。没有每个目录的文件“最大数量”，而是每个目录的“用于存储文件条目的最大块数量”。具体来说，目录本身的大小不能超过高度为3的b-树，并且树的扇出取决于块大小。有关详细信息，请参见此链接。

https://www.mail-archive.com/cwelug@googlegroups.com/msg01944.html

我最近在一个格式化为2K块的文件系统上就遇到过这种情况，它莫名其妙地得到目录已满的内核消息警告:ext3_dx_add_entry:目录索引已满!当我从另一个ext3文件系统复制时。在我的例子中，一个只有480,000个文件的目录无法复制到目标。

我也有同样的问题。试图在ext4的Ubuntu服务器中存储数百万个文件。结束运行我自己的基准测试。发现平面目录执行得更好，同时使用起来更简单:

写了一篇文章。