Answers:
如果您有支持该dir_index功能的发行版，则可以在单个目录中轻松存储200,000个文件。为了安全起见，我将其保持在25,000左右。如果没有dir_index，请尝试将其保持在5,000。
要非常小心，你如何选择目录拆分。“ a / b / c”听起来像是对我造成灾难的秘诀...
不要盲目地制作几个目录的深层结构，例如，第一层为100个条目，第二层为100个条目，第三层为100个条目。我去过那里，做了那件事，当性能下降到只有几百万个文件时，不得不重新整理夹克。:-)
我们有一个进行“多个目录”布局的客户端，最终每个目录只放置一到五个文件，这正在杀死它们。3至6个小时在此目录结构中执行“ du”操作。这里的救星是SSD，他们不愿意重写应用程序的这一部分，而SSD将这段时间从几小时缩短到了几分钟。
问题是目录查找的每个级别都要进行搜索，而搜索非常昂贵。目录的大小也是一个因素，因此，使目录变小而不是变大是一个大胜利。
为了回答有关每个目录有多少个文件的问题，我听说有1,000个文件被称为“最佳”文件，但性能最好为10,000个文件。
因此，我建议您使用一个目录级别，每个级别是一个目录，该目录长2个字符，由大写和小写字母以及数字组成，用于顶层的大约3800个目录。然后，您可以保存包含这些子目录的14M文件，这些子目录包含3800个文件，对于3M文件，每个子目录大约包含1,000个文件。
我为另一个客户进行了这样的更改，它产生了巨大的变化。
http://en.wikipedia.org/wiki/Ext3#Functionality-提到目录只能包含大约32000个子目录，但没有提及文件。
http://roopindersingh.com/2008/05/10/ext3-handling-large-number-of-files-in-a-directory/
另外，我讨厌Experts Exchange，但我读到有关此问题的评论，每个目录的数量最好少于10-15,000。
以我的经验，最好的方法是不要预先过度设计文件结构。正如至少一个其他答案中提到的那样，存在一些文件系统扩展来处理性能问题。
我最常遇到的问题是管理端的可用性。您减少目录中文件数量所能做的最少工作就是您现在需要的方法。
sqrt（3_000_000）== 1732
在一个目录中有数千个文件对我来说听起来很合理。做自己的判断自己的情况。为此，请尝试将文件分成单个级别的哈希目录，以使每个目录的平均文件数与目录数大致相同。
鉴于您的例子，这将是./a/abc.ext，./ab/abc.ext，./abc/abc.ext，...。
文件的传播将在很大程度上取决于实际的文件名。想象一下，将这种技术应用于一百万个文件目录，每个文件名为foobar???.txt。有一些方法可以实现更均匀的扩展，例如基于每个文件名的MD5总和中特定数量的位的值进行散列，但是我敢于猜测这对于您要实现的目标而言是过高的。