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

写了一篇文章。

我遇到的最大问题是在32位系统上。一旦你通过了一个特定的数字，像'ls'这样的工具就会停止工作。

一旦您通过了这个障碍，试图对该目录做任何事情都将成为一个巨大的问题。

我尊重这并不能完全回答你的问题，多少是太多了，但解决长期问题的一个想法是，除了存储原始文件元数据外，还存储它存储在磁盘上的哪个文件夹-规范化元数据。一旦一个文件夹的增长超出了性能、美观或其他原因的限制，你只需创建第二个文件夹并开始在那里放置文件……

问题归结为你将如何处理这些文件。

在Windows下，对于我来说，在资源管理器中打开任何超过2k个文件的目录都比较缓慢。如果它们都是图像文件，在缩略图视图中，超过1k的文件往往打开得非常慢。

系统规定的上限曾一度是32767个。现在它更高了，但即使如此，在大多数情况下，一次处理的文件也太多了。

如果实现目录分区方案所涉及的时间是最少的，我赞成它。当您第一次调试涉及通过控制台操作10,000个文件目录的问题时，您将能够理解。

例如，F-Spot将照片文件存储为YYYY\MM\DD\filename。ext，这意味着在手动操作我的~20000张照片集合时，我必须处理的最大目录大约有800个文件。这也使文件更容易从第三方应用程序中浏览。永远不要以为只有你的软件会访问你的软件文件。

请记住，在Linux上，如果目录中有太多文件，shell可能无法展开通配符。我在Linux上托管的相册有这个问题。它将所有调整大小的图像存储在一个目录中。虽然文件系统可以处理许多文件，但shell不能。例子:

-shell-3.00$ ls A*
-shell: /bin/ls: Argument list too long

or

-shell-3.00$ chmod 644 *jpg
-shell: /bin/chmod: Argument list too long