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

如果单个目录中有100万个单独的文件(大多数为10万个),平坦地(没有其他目录和文件),是否会有任何其他可能的方式效率或劣势的妥协?

Solutions Collecting From Web of "如果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的限制。