【问题标题】：How many sub-directories should be put into a directory一个目录应该放多少个子目录
【发布时间】：2010-10-04 10:18:51
【问题描述】：

在 SO 上，关于一个目录中有多少文件是合适的，已经有很多讨论：在旧文件系统上保持在几千以下，而在新文件系统上保持在几十万以下。通常建议是为每几千个文件创建一个子目录。

所以下一个问题是：我应该放入一个目录的最大子目录数量是多少？将它们嵌套得太深会破坏 dir 树遍历性能。有没有将它们嵌套到浅层？

【问题讨论】：

标签： operating-system filesystems

【解决方案1】：

从实用性的角度来看，应用程序可能无法很好地处理大型目录条目。例如，Windows 资源管理器被数千个目录条目所困扰（我遇到过 Vista 崩溃，但 XP 似乎处理得更好）。

由于您提到嵌套目录，还请记住，完全限定（带有驱动器指示符和路径）文件名 (See wikipedia 'filename' entry) 的长度是有限制的。这将随操作系统文件系统(See Wikipedia 'comparison on file systems' entry) 而变化。

对于 Windows NTFS，它应该是 255，但是，我遇到了命令和 API 函数的问题，其中完全限定的文件名大约为 120 个字符。我也遇到了映射网络驱动器上长路径名的问题（至少在 Vista 和 I.E. Explorer 7 中）。

子目录的嵌套级别也有限制。例如，CD-ROM (ISO 9660) 被限制为 8 个目录级别（如果您想将目录结构复制到 CD-ROM 或其他文件系统，请记住这一点）。

所以当你把文件系统推到极端时会有很多不一致的地方（虽然理论上文件系统可能能够处理它，但应用程序和库可能无法处理）。

【讨论】：

【解决方案2】：

实际上取决于您使用的操作系统，因为目录操作是使用系统调用完成的。对于基于 unix 的操作系统，i-node 查找算法非常高效，目录中的文件和文件夹数量无关紧要。可能这就是为什么在基于 Unix 的系统中没有限制的原因。但是，在 Windows 中，it varies from file-system to file-systems。

【讨论】：

【解决方案3】：

通常现代文件系统（如 NTFS 或 ext3）直接访问文件没有问题（即，如果您尝试打开 /foo/bar/baz.dat）。您可能会遇到问题的地方是枚举给定目录中的子目录/文件（即，给我 /foo 中的所有文件/目录）。这可能发生在多种情况下（例如在调试期间或在备份期间等）。我发现，将孩子数保持在最多几百个左右可以给我可接受的响应时间。

当然，这因情况而异，因此请进行测试:-)

【讨论】：

【解决方案4】：

我的猜测尽可能少。

在我工作的 ISP（早在 2003 年），我们有很多用户电子邮件和网络文件。我们使用 md5 散列用户名构建它们，深度为 3 级（即 /home/a/b/c/abcuser）。这导致在第三级目录中可能有多达 100 个用户。

您也可以使用浅层结构的用户目录来构建更深的结构。最好的选择是尝试查看，但目录数越小查找速度越快。

【讨论】：

【解决方案5】：

我最近遇到了类似的情况。我们使用文件系统来存储序列化的交易细节。这些只会很少被查看，将它们存储在数据库中是不值得的。

我们发现 Windows 和 Linux 可以处理大约一千个文件，但访问它们的速度确实要慢得多 - 我们将它们组织在逻辑分组中的子目录中，这解决了问题。

grep 也更容易。搜索数千个文件比更改到正确的子目录并搜索数百个文件要慢。

【讨论】：

【解决方案6】：

在 Windows API 中，maximum length 设置为 260 个字符。 unicode 函数确实将此限制扩展到 32767 个字符，主要文件系统使用。

【讨论】：

【解决方案7】：

我发现 UFS2 的限制大约是 2^15 个子目录。因此，虽然 UFS2 和其他现代文件系统在一个目录中处理几十万个文件时可以很好地工作，但它只能处理相对较少的子目录。不明显的错误消息是“无法创建链接”。

虽然我还没有测试过 ext2，但我发现了各种邮件列表帖子，其中发帖者在 ext2 文件系统上也存在超过 2^15 个文件的问题。

【讨论】：