不是答案，只是一些建议。

选择一个更合适的FS(文件系统)。因为从历史的角度来看，你们所有的问题都是足够明智的，在过去几十年里曾经是金融服务体系演变的核心。我的意思是更现代的FS更好地支持你的问题。首先从FS列表中做出一个基于你最终目的的比较决策表。

我认为是时候改变你的思维模式了。所以我个人建议使用分布式系统支持的FS，这意味着在大小、文件数量等方面没有任何限制。否则，你迟早会遇到意想不到的新问题。

我不确定这是否有效，但如果您没有提到一些实验，请尝试一下当前文件系统上的AUFS。我想它可以将多个文件夹模拟为单个虚拟文件夹。

为了克服硬件限制，可以使用RAID-0。

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

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

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

我在一个ext3目录中有超过800万个文件。Libc readdir()， find, ls和本线程中讨论的大多数其他方法都使用它来列出大型目录。

ls和find在这种情况下很慢的原因是readdir()一次只读取32K的目录条目，所以在慢磁盘上需要很多很多次读取才能列出一个目录。这个速度问题有一个解决方案。我在http://www.olark.com/spw/2011/08/you-can-list-a-directory-with-8-million-files-but-not-with-ls/上写了一篇非常详细的文章

关键是:直接使用getdings()——http://www.kernel.org/doc/man-pages/online/pages/man2/getdents.2.html，而不是任何基于libc readdir()的方法，这样在从磁盘读取目录条目时就可以指定缓冲区大小。

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

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

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

没有一个数字是“太多”的，只要它不超过操作系统的限制。然而，不管哪种操作系统，一个目录中的文件越多，访问任何单个文件所需的时间就越长，而且在大多数操作系统上，性能是非线性的，因此从10,000个文件中找到一个文件所需的时间是在1,000个文件中找到一个文件所需的时间的10倍以上。

与目录中有大量文件相关的次要问题包括通配符展开失败。为了降低风险，您可以考虑根据上传日期或其他有用的元数据对目录进行排序。

上面的大多数答案都没有说明，对于最初的问题，没有“一刀切”的答案。

In today's environment we have a large conglomerate of different hardware and software -- some is 32 bit, some is 64 bit, some is cutting edge and some is tried and true - reliable and never changing. Added to that is a variety of older and newer hardware, older and newer OSes, different vendors (Windows, Unixes, Apple, etc.) and a myriad of utilities and servers that go along. As hardware has improved and software is converted to 64 bit compatibility, there has necessarily been considerable delay in getting all the pieces of this very large and complex world to play nicely with the rapid pace of changes.

恕我直言，没有一种方法可以解决问题。解决办法是研究各种可能性，然后通过反复试验找到最适合你特定需求的方法。每个用户必须确定什么适合他们的系统，而不是使用千篇一律的方法。

I for example have a media server with a few very large files. The result is only about 400 files filling a 3 TB drive. Only 1% of the inodes are used but 95% of the total space is used. Someone else, with a lot of smaller files may run out of inodes before they come near to filling the space. (On ext4 filesystems as a rule of thumb, 1 inode is used for each file/directory.) While theoretically the total number of files that may be contained within a directory is nearly infinite, practicality determines that the overall usage determine realistic units, not just filesystem capabilities.

我希望以上所有不同的答案都能促进思考和解决问题，而不是成为进步的不可逾越的障碍。