我有一个应用程序正在写入一个 ext3 目录，随着时间的推移，该目录已增长到大约 300 万个文件。不用说，读取此目录的文件列表的速度慢得令人难以忍受。
我不怪 ext3。正确的解决方案应该是让应用程序代码写入诸如 之类的子目录，./a/b/c/abc.ext而不是仅使用./abc.ext。
我正在更改为这样的子目录结构，我的问题很简单：在一个 ext3 目录中，我大概应该存储多少个文件，同时仍能获得可接受的性能？您的经验是什么？
或者换句话说；假设我需要在结构中存储三百万个文件，那么./a/b/c/abc.ext结构深度应该是多少级？
显然这是一个无法准确回答的问题，但我正在寻找一个大概的估计。
答案1
假设您有一个支持该功能的发行版dir_index，那么您可以在一个目录中轻松拥有 200,000 个文件。不过，为了安全起见，我会将其保持在 25,000 个左右。如果没有dir_index，请尝试将其保持在 5,000 个。
答案2
是非常请小心选择目录拆分。“a/b/c”对我来说听起来像是灾难的根源……
不要盲目地去构建一个多层目录结构，比如第一层 100 个条目，第二层 100 个条目，第三层 100 个条目。我曾经遇到过这种情况，做过这件事，拿到了夹克，但当性能因为几百万个文件而变得糟糕时，我不得不重新构建它。:-)
我们有一个客户，他采用了“多目录”布局，但最终每个目录只放了一到五个文件，这让他们非常头疼。在这个目录结构中执行“du”需要 3 到 6 个小时。救星是 SSD，他们不愿意重写应用程序的这一部分，而 SSD 将 du 时间从几小时缩短到了几分钟。
问题是每一级目录查找都需要搜索，而搜索的代价非常高昂。目录的大小也是一个因素，因此目录越小越好。
回答您关于每个目录有多少个文件的问题，我听说 1,000 个文件被认为是“最佳”，但 10,000 个文件的性能似乎也很好。
因此，我建议使用一层目录，每层目录长度为 2 个字符，由大小写字母和数字组成，顶层目录约有 3800 个。然后，您可以保存 14M 文件，这些子目录包含 3800 个文件，或者每个子目录约有 1,000 个文件，每个子目录包含 3M 文件。
我已经为另一个客户做过类似的改变，并且产生了巨大的变化。
答案3
我建议您尝试使用基准测试工具测试各种目录大小，例如邮戳，因为有很多变量（例如缓存大小（在操作系统和磁盘子系统中））取决于您的特定环境。
我个人的经验法则是将目录大小设为 <= 20k 个文件，尽管我也看到过每个目录最多 100k 个文件时性能相对不错。
答案4
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 个。