子目录的数量如何影响Linux上的驱动器读/写性能？

这很容易在自己的环境中testing自己的选项，并比较结果。 是的，随着目录数量的增加，会对性能产生负面影响。 是的，其他文件系统可以帮助解决这些障碍或减less影响。

XFS文件系统更适合这种types的目录结构。 ext4现在可能就好了。 随着子目录和文件数量的增加，对目录的访问和操作将会变慢。 这在ext3下非常明显，而在XFS上则没有。

答案并不像select文件系统那么简单。 很久以前，Sane文件系统就停止使用线性列表，这意味着目录中的条目数量不会影响文件访问时间….

除非是这样。

实际上，无论input的数量如何，每个操作都保持快速和高效，但是一些任务涉及越来越多的操作。 显然，做一个简单的ls需要很长时间，直到所有的inode被读取和sorting后，才会看到一个东西。 做ls -U （未sorting）会有所帮助，因为你可以看到它没有死，但是并没有减less时间感知。 不太明显的是，任何通配符扩展都必须检查每个文件名，而且在大多数情况下，似乎也必须读取整个inode。

简而言之：如果你确信没有应用程序（包括shell访问）会使用任何wildard，那么你可以得到巨大的目录没有任何悔恨。 但是如果代码中可能存在一些通配符，那么每个目录最好不要超过一千个。

编辑 ：

所有的现代文件系统对于大目录都使用良好的数据结构，因此即使在庞大的目录中，单个操作必须能够find特定文件的索引节点。

但是，大多数应用程序不只是单一操作。 他们中的大多数将做完整的目录或通配符匹配。 无论如何，这些都很慢，因为它们涉及阅读所有条目。

例如：可以说你有一个名为“foo-000000.txt”到“foo-999999.txt”和一个“natalieportman.jpeg”的百万个文件的目录。 这些将会很快：

• ls -l foo-123456.txt
• open "foo-123456.txt"
• delete "foo-123456.txt"
• create "bar-000000.txt"
• open "natalieportman.jpeg"
• create "big_report.pdf"

这些会失败，但也会失败：

• ls -l bar-654321.txt
• open bar-654321.txt
• delete bar-654321.txt

这些会很慢，即使他们返回的结果很less; 即使是那些失败，扫描所有条目后失败：

• ls
• ls foo-1234*.txt
• delete *.jpeg
• move natalie* /home/emptydir/
• move *.tiff /home/seriousphotos/

首先确保ext3分区设置了dir_index标志。

 sudo dumpe2fs /dev/sdaX |grep --color dir_index 

如果缺less，可以启用它。 您需要卸载文件系统，然后运行：

 sudo tune2fs -O dir_index /dev/sdaX sudo e2fsck -Df /dev/sdaX 

然后挂载文件系统。

直到你达到每个目录限制的ext3 32,000个名字为止，这没什么区别。 升级到ext4可以解决这个问题，以及ext4的其他好处。

你在一个目录中有更多的条目（文件和目录），访问速度就会变慢。 对于每个文件系统都是如此，虽然有些比其他文件系统更糟糕。

更好的解决scheme是创build一个目录层次结构，如下所示：

 /users/a/aaron/ /users/a/andrew/ /users/b/betty/ /users/b/brian/ 

如果你还需要更好的performance，你可以扩展多个层面：

 /users/a/a/aaron /users/a/n/anna /users/a/n/andrew 

大多数邮件系统使用这个技巧与他们的邮件队列文件。

另外，我发现在一些文件系统中，过去只有在一个目录中有许多条目才会使目录访问变慢。 在目录上执行ls -ld以查看目录条目本身的大小。 如果它是几MB或更多，并且目录是相对空的，那么你的性能可能会变差。 重命名该目录，创build一个具有相同名称，权限和所有权的新目录，然后将旧目录的内容移动到新目录中。 我多次使用这个技巧来显着加速邮件服务器，这些邮件服务器由于文件系统而变慢。

我最近开发了一个存储服务器，需要创build数以千万计的文件和数十万个目录。 我将XFS与ext4和reiserfs进行了比较。 我发现在我的情况下，ext4比XFS稍快。 Reiser是有趣的，但有限制，所以被放弃。 我也发现ext4比ext3快得多。

当你为每个目录获取大量文件时，文件打开时间开始受到影响。 文件I / O不。 文件删除时间也受到影响。 但是，ext4的速度并不算太慢。 但是在ext3下它很明显。 XFS和ext4在这方面相当快。

当我上次查看XFS并且正在权衡使用XFS而不是ext4的优点和缺点时，我发现了XFS数据丢失的报告。 我不确定这是否还是一个问题，或者是否有问题，但是让我感到很紧张。 由于ext4是Ubuntu中的默认fs，所以它很容易通过XFS获胜。

所以，除了tylerl的build议，从pipe理的angular度来看，我build议你可以升级到ext4。 每个目录限制是ext4的64000条目

另一个好处是fsck的时间要快得多。 我从来没有任何腐败问题。

关于ext4的好处是，你可以挂载一个ext3卷到ext4来试用。 请参阅： 将实时系统从ext3迁移到ext4文件系统

来自该链接的引用：

如果你不受ext3的限制，不愿意承担风险，可能不值得。 另一方面，在成功完成迁移过程之后，您的系统可能执行得更快，体验缩短的文件系统检查，并增加了可靠性，没有不良影响。

所以，继续尝试吧。 build议先备份。

肯定会有这样做的一些后果。 主要的是IO读/写。 除此之外，这只是处理这种types的数据（在这个规模）的一个非常可怕的方式。

在过去，我使用XFS来成功解决Ext3的限制。

文件系统内容的第一个列表需要一段时间，直到系统读取了所有的目录/文件信息。 补充操作会更快，因为内核现在已经caching了信息。

我已经看到pipe理员定期在cron中运行“find / somepath 2>＆1> / dev / null”来保持高速caching的活跃，从而获得更好的性能。

我有一些问题和一些可能的瓶颈发现。

首先，这是CentOS 5或6系统吗？ 因为在6，我们有一个令人难以置信的工具，称为blktrace，这是测量在这种情况下的影响的理想select。

 https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/ch06s03.html 

然后，我们可以使用bttparsing输出，并获取瓶颈所在，应用程序，文件系统，调度程序，存储 – IO大部分时间花费在哪个组件上。

现在，从理论上来说，你的问题会明显增加inode的数量，并且随着你不断创build或访问目录中的新的或现有的文件或目录，访问时间将会增加。 内核必须遍历更大的文件系统层次结构，因此毫无疑问是一个开销。

还有一点需要注意的是，随着你增加目录的数量，inode和dentry的caching使用率将会攀升，意味着消耗更多的内存。 这是在slab内存下，所以如果你的服务器内存不足，这是另一个想法。

说到一个真实世界的例子，我最近看到，在一个高度嵌套的ext3 fs上，第一次创build一个subdir需要大约20秒，而ext4需要大约4秒。 这是因为块分配是如何在不同的文件系统中构造的。 如果你使用XFS或ext4，不用说，你会得到一些性能提升，但最低限度可能。

所以，如果你只是问什么是正确的文件系统select，ext3是有点过时了。 这就是我所能提供的，没有进一步的数据和基准。

这不是CentOS 5上的选项，也不知道CentOS 6上的选项是多less，但我有一种直觉，即一种基于B树或B *树的解决scheme，即BTRFS，即使在你的特定性能情况下，如果只有一个人可以把自己的宝贵资料和清楚的良知交托给我（我还是不会）。

但如果你能负担得起，你可以testing它。