12

如果单个目录中有大约 1,000,000 个单独的文件（大小大多为 100k），平坦（其中没有其他目录和文件），是否会以任何其他可能的方式降低效率或劣势？

4

6 回答 6

7

ARG_MAX 会对此提出异议……例如， rm -rf * （在目录中）会说“参数太多”。想要进行某种通配（或外壳）的实用程序将有一些功能中断。

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

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

编辑：

ARG_MAX 是一个系统范围的限制，限制了可以向程序的入口点提供多少参数。因此，让我们以“rm”为例，以“rm -rf *”为例——shell 会将“*”转换为以空格分隔的文件列表，该列表又将成为“rm”的参数。

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

我建议（无论使用什么 fs ）将其分解为更小的目录块，仅出于这个原因。

于 2009-03-18T09:16:40.757 回答
4

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

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

但是，如果没有dir_index，您真的被搞砸了:-D

于 2009-03-18T09:43:45.980 回答
3

当你不小心在那个目录中执行了“ls”，或者使用了tab补全，或者想要执行“rm *”，你就会遇到大麻烦。此外，可能存在性能问题，具体取决于您的文件系统。

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

啊啊/
   aaavnj78t93ufjw4390
   aaavoj78trewrwrwrwenjk983
   aaaz84390842092njk423
   ...
ABC/
   abckhr89032423
   abcnjjkth29085242nw
   ...
...
于 2009-03-18T09:23:55.047 回答
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为要为其激活它的分区。

于 2009-03-18T09:26:09.487 回答
1

显而易见的答案是，在任何技术限制之前很久，人类就很难使用该文件夹，（读取 ls 的输出所花费的时间是一个原因，还有很多其他原因）您是否有充分的理由不能拆分进入子文件夹？

于 2009-03-18T09:27:13.650 回答
0

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

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

于 2009-07-02T07:57:30.857 回答