一个目录应该放多少子目录

从实用性的角度来看,应用程序可能无法很好地处理大型目录条目。 例如,Windows资源管理器陷入了数千个目录条目的困境(我遇到了Vista崩溃,但XP似乎能更好地处理它)。

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

但是,对于WindowsNTFS,它应该是255,我遇到了命令和API函数的问题,这些命令和API函数的文件名完全限定在120个字符左右。我还遇到了映射网络驱动器上的长路径名问题(至少在Vista和Explorer 7上)。

子目录的嵌套级别也有限制。例如,CD-ROM(iso 9660)仅限于8个目录级别(如果要将目录结构复制到CD-ROM或其他文件系统,请记住这一点)。

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

实际上取决于您使用的操作系统,因为目录操作是使用系统调用完成的。对于基于Unix的操作系统,i节点查找算法效率很高,目录中的文件和文件夹数量也不重要。可能这就是为什么在基于Unix的系统中它没有限制的原因。但是,在Windows中, it varies from file-system to file-systems .

哇,你真的创建了这么多文件以至于这很重要吗?也许您应该重新检查您的文件创建策略:—)。

说真的,我想不出在很多情况下,我的子目录中甚至会有一千个文件。当然不是可执行或配置类型。

也许日志类型的文件可以达到这样的数字,但是,即使你每分钟都要创建一个日志文件(为什么要这样做?)每天只剩下1400多。

然后每天只需要一个子目录,并且需要几年时间才能到达一千个子目录。

通常,现代文件系统(如ntfs或ext3)直接访问文件没有问题(例如,如果您试图打开/foo/bar/baz.dat)。您可能会遇到问题的地方是枚举给定目录中的子目录/文件(即,给我/foo中的所有文件/dirs)。这可能发生在多个场景中(例如在调试或备份等过程中)。我发现让儿童人数最多保持在几百人左右给了我可以接受的回答时间。

当然,这在不同的情况下是不同的,测试也是如此:—)

我的猜测是尽可能少的。

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

您也可以使用浅层结构中的用户目录进行更深层次的结构。最好的选择是尝试查看,但是目录计数越小查找越快。

我最近也遇到过类似的情况。我们使用文件系统来存储序列化的交易详细信息。这些只会很少被看到,而把它们存储在数据库中是不值得的。

我们发现Windows和Linux处理了大约1000个文件,但是访问它们的速度慢得多——我们按照逻辑分组将它们组织在子目录中,这样就解决了这个问题。

他们也更容易变灰。对数千个文件进行grepping比更改为正确的子目录和对几百个文件进行grepping慢。

我发现对于ufs2来说,最难的方法是限制在2^15子目录左右。因此,虽然ufs2和order现代文件系统在处理一个目录中的几十万个文件时相当得体,但它只能处理相对较少的子目录。不明显的错误消息是“无法创建链接”。

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

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