如果Linux中单个目录下的文件太多，会发生什么情况？

ARG_MAX将会考虑到这个问题……例如，rm -rf *（在目录中）会说“太多的参数”。 想要做某种globbing（或shell）的工具将会有一些功能中断。

如果该目录对公众可用（可以通过ftp或web服务器说），则可能会遇到其他问题。

对任何给定文件系统的影响完全取决于该文件系统。 这些文件的访问频率如何，文件系统是什么？ 请记住，根据您的设置，Linux（默认情况下）优先将最近访问的文件保存在内存中，同时将进程置于交换状态。 这个目录是通过http服务的吗？ Google会看到并抓取它吗？ 如果是这样，您可能需要调整VFS缓存压力和swappiness。

编辑：

ARG_MAX是一个系统范围的限制，可以将多少个参数呈现给程序的入口点。 因此，让我们拿“rm”，例如“rm -rf *” – shell将把'*'转换成空格分隔的文件列表，然后转换成rm的参数。

ls和其他几个工具也会发生同样的情况。 例如，如果太多的文件以'foo'开始，ls foo *可能会中断。

我建议（无论使用哪个fs）把它分解成更小的目录块，仅仅是因为这个原因。

我在启用ext3和dir_index大型目录上的经验：

• 如果您知道要访问的文件的名称，则几乎不会有任何处罚
• 如果你想做整个目录条目的操作（比如简单的ls在这个目录下），第一次需要几分钟的时间。 然后该目录将保留在内核缓存中，不会有任何处罚
• 如果文件数量太多，会遇到ARG_MAX等问题。 这基本上意味着通配符（ * ）并不总是按预期工作。 这只有当你真的想要一次执行所有文件的操作

没有dir_index但是，你真的搞砸了:-D

大多数发行版默认使用Ext3 ，可以使用大型目录的b-tree索引。 一些发行版本具有默认启用的dir_index功能，您必须自己启用它。 如果启用它，即使对于数百万个文件也没有减速。

查看dir_index功能是否被激活（作为root）：

 tune2fs -l /dev/sdaX | grep features 

激活dir_index功能（以root身份）：

 tune2fs -O dir_index /dev/sdaX e2fsck -D /dev/sdaX 

将/dev/sdaX替换为要激活的分区。

当你不小心在那个目录下执行“ls”，或者使用tab完成，或者想要执行“rm *”时，你会遇到很大的麻烦。 此外，根据您的文件系统，可能会有性能问题。

将文件分组到文件名的前2或3个字符所指定的目录中被认为是很好的做法，例如

 AAA /
    aaavnj78t93ufjw4390
    aaavoj78trewrwrwrwenjk983
    aaaz84390842092njk423
    ...
 ABC /
    abckhr89032423
    abcnjjkth29085242nw
    ...
 ...

显而易见的答案是，在任何技术限制之前，文件夹对于人类来说是非常困难的（读取来自ls的输出所需要的时间，他们有几十个其他的原因）是不是有一个很好的理由，到子文件夹？

并不是每个文件系统都支持这么多文件。

其中一些（ext2，ext3，ext4）很容易达到inode的限制。