Question

如果单个目录中有1,000,000个单独的文件（大多数是100k），那么平坦（没有其他目录和文件），在任何其他可能的方式中，效率或缺点是否会有任何妥协？< / p>

Answer 1

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）将其分解为更小的目录块，仅仅是出于这个原因。

Answer 2

当您意外地在该目录中执行“ls”，或使用制表符完成，或者想要执行“rm *”时，您将遇到大麻烦。此外，根据您的文件系统，可能会出现性能问题。

将文件分组到由文件名的前2个或3个字符命名的目录中是一种很好的做法，例如

aaa/
   aaavnj78t93ufjw4390
   aaavoj78trewrwrwrwenjk983
   aaaz84390842092njk423
   ...
abc/
   abckhr89032423
   abcnjjkth29085242nw
   ...
...

Answer 3

默认情况下，大多数发行版使用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替换为您要激活它的分区。

Answer 4

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

如果您知道要访问的文件的名称，则几乎没有任何处罚
如果您想进行需要读取整个目录条目的操作（如该目录上的简单ls），则首次需要几分钟。然后该目录将保留在内核缓存中，不再有任何惩罚
如果文件数量过高，则会遇到ARG_MAX等问题。这基本上意味着通配符（*）并不总是按预期工作。仅当您确实想要一次对所有文件执行操作时

然而，如果没有dir_index，你真的搞砸了:-D

Answer 5

显而易见的答案是，在任何技术限制之前，人类很难长时间使用文件夹，（从ls读取输出所需的时间，其他几十个原因）是否有充分的理由让你能够分成子文件夹？

Answer 6

并非每个文件系统都支持那么多文件。

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

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

6 个答案: