一个 ext3 目录中的最大文件数同时仍能获得可接受的性能？

Question

我有一个写入 ext3 目录的应用程序，随着时间的推移，该目录已增长到大约 300 万个文件。不用说，读取这个目录的文件列表是慢得无法忍受的。

我不怪 ext3。正确的解决方案是让应用程序代码写入子目录，例如./a/b/c/abc.ext而不是仅使用./abc.ext.

我正在更改这样的子目录结构，我的问题很简单：我应该期望在一个 ext3 目录中存储大约多少文件，同时仍能获得可接受的性能？你有什么经验？

或者换句话说；假设我需要在结构中存储 300 万个文件，该结构应该有多少层深./a/b/c/abc.ext？

显然，这是一个无法准确回答的问题，但我正在寻找一个球场估计。

Answer 1

如果您有一个支持该dir_index功能的发行版，那么您可以轻松地在单个目录中拥有 200,000 个文件。不过，为了安全起见，我会将其保持在 25,000 左右。如果没有dir_index，请尝试将其保持在 5,000。

Answer 2

选择目录拆分方式时要非常小心。“a/b/c”对我来说听起来像是灾难的秘诀......

不要盲目地去制作几个目录的深层结构，比如第一级100个条目，第二级100个条目，第三级100个条目。我去过那里，做了那件事，拿到了夹克，当性能下降时，有几百万个文件，我不得不对其进行重组。:-)

我们有一个客户端进行了“多目录”布局，最终每个目录只放置一到五个文件，这正在杀死它们。3到6个小时在这个目录结构中做一个“du”。这里的救星是 SSD，他们不愿意重写他们应用程序的这部分，而 SSD 将这个 du 时间从几小时缩短到几分钟。

问题是每个级别的目录查找都需要查找，并且查找非常昂贵。目录的大小也是一个因素，所以让它更小而不是更大是一个很大的胜利。

要回答您关于每个目录有多少文件的问题，我听说 1,000 是“最佳”，但 10,000 的性能似乎很好。

所以，我推荐的是一级目录，每一级是一个 2 个字符长的目录，由大小写字母和数字组成，顶层大约有 3800 个目录。然后，您可以使用包含 3800 个文件的子目录来保存 14M 文件，或者对于 3M 文件，每个子目录可以保存大约 1,000 个文件。

我为另一个客户做了这样的改变，它产生了巨大的不同。

Answer 3

我建议您尝试使用诸如postmark 之类的基准测试工具测试各种目录大小，因为有很多变量，例如缓存大小（在操作系统和磁盘子系统中）取决于您的特定环境。

我个人的经验法则是将目录大小设为 <= 20k 文件，尽管我已经看到了高达 100k 文件/目录的相对不错的性能。