Kladskull Asked: 2009-06-04 12:05:52 +0800 CST2009-06-04 12:05:52 +0800 CST 2009-06-04 12:05:52 +0800 CST 将文件存储在目录中...有限制吗？ 772 我正在使用带有 Plesk 9（64 位）的 CentOS 5，我正在运行一个用户将上传图片的网站。使用 64 位操作系统，我可以存储多少个文件有任何限制吗？我只关心性能和提供文件。我不希望有 4 个目录深的分散文件。但是，我希望在某个时候我可以拥有 200-30 万张图像。 linux filesystems directory limitations 9 个回答 Voted Best Answer voyager 2009-06-04T12:41:48+08:002009-06-04T12:41:48+08:00 如果您使用的是 ext3，我发现了这句话（警告：西班牙语网站） “单个目录中有 32k (32768) 个子目录的限制，这个限制可能只是学术兴趣，因为许多人甚至没有那么多文件（尽管可能需要记住巨大的邮件服务器）。 ext2 inode 规范允许超过 100 万亿个文件驻留在单个目录中” 进一步阅读表明 ext3没有32K 的限制，这可以通过经验证明 a=0; i=1; while [ $a == 0 ]; do touch $i; a=$?; let i++; done 但它确实有文件夹的 32K 文件夹限制，可以用 a=0; i=1; while [ $a == 0 ]; do mkdir $i; a=$?; let i++; done 这个（没有根据的）声称说 ReiserFS 在单个目录中处理数十万个文件时完全没有问题。平板电脑 - 2007 年 2 月 1 日 来自姊妹网站 stackoverflow.com 的这个问题也可以提供帮助。 一般来说： 目录数量有限制， 您应该将文件/目录保持在 32K 以下，但可以走得更远， 您使用的文件系统确实很重要。 sysadmin1138 2009-06-04T12:11:44+08:002009-06-04T12:11:44+08:00 这很大程度上取决于您使用的文件系统。某些旧版本的 ext3 在这方面很糟糕，这就是 btrees 的产生方式。Reiser 在处理大量此类文件时性能要高得多。在过去，由于 GroupWise 的故障，我在 NetWare 服务器上有一个 Novell NSS 目录，其中包含 250,000 个 4kb 的文件，它工作得很好。枚举目录很麻烦，但是访问该目录中的特定文件的速度与您希望的一样快。就像 8 年前一样，我必须假设现代 Linux 文件系统可以沉着应对。 Evan Anderson 2009-06-04T12:12:07+08:002009-06-04T12:12:07+08:00 这取决于您使用的文件系统，而不是操作系统的 64 位。对于每个文件系统，都会有某个时刻，用于搜索目录的算法的大 O 成本会变得更好。 如果您可以将文件层次结构分解为两 (2) 层层次结构，您将看到更好的长期可扩展性。 Alexandre Carmel-Veilleux 2009-06-04T12:21:29+08:002009-06-04T12:21:29+08:00 Linux存储目录中的文件系统基本上有两种方式： 作为文件的平面列表。 作为数据结构（通常是 B+Tree 或相关数据结构）。 随着文件的添加，前者会逐渐变慢。后者没有。请注意， ls 可能仍然需要很长时间，因为它必须查找所有这些文件的 inode，目录条目仅包含文件名和 inode 编号。 Ext3 目录是平面列表，带有哈希树索引选项以加快处理速度。 XFS 使用 B+树。 但是对于这些文件系统中的任何一个，如果您执行 ls -l，它需要命中与文件一样多的 inode。对于名称查找（例如打开文件时），B+Tree 和类似的东西对于大型目录来说会快得多。 然而，目录层次结构使管理文件更容易，因此您可能需要考虑这种可能性。即使是单层目录，例如每个目录限制为 4000 个文件，也会使事情更容易管理。 Dan Udey 2009-06-06T14:36:24+08:002009-06-06T14:36:24+08:00 如果您要超过几百张图片，请务必考虑两件事： 带有散列文件名的嵌套层次结构； 不使用 ext3 我建议使用 XFS，或者，如果不这样做，则使用 ReiserFS，将两层或三层深度的目录层次结构按两字节对划分。例如 11/2f/112f667c786eac323e300632b5b2a78d.jpg 49/2f/49ef6eb6169cc57d95218c842d3dee5c.jpg 0a/26/0a26f9f363f1d05b94ceb14ff5f27284.jpg 这将在前几个级别为您提供 256 个目录，将图像拆分为总共 65535 个单独的目录（对于 100-200k 图像及更多图像来说绰绰有余）。它将使事情变得更快，更具可扩展性，并且也使以后的维护变得更加容易。 Martin M. 2009-06-04T12:19:43+08:002009-06-04T12:19:43+08:00 ext3 的大多数默认配置限制每个目录有 32K 子目录（现在无法记住实际数量，但我们在几周前遇到了这个问题，当时系统是 Debian/Etch）。 在一些使用大量缓存的应用程序中也可能会打击你。 Tom Newton 2009-06-04T12:37:58+08:002009-06-04T12:37:58+08:00 当然，考虑不使用 ext3。 http://kernelnewbies.org/Ext4#head-97cbed179e6bcc48e47e645e06b95205ea832a68 （显示 ext4 中的新功能）可能是一个有用的起点。 会说看看 squid 如何组织它的缓存（多层目录），因为一个目录中的许多文件可能很难维护。长列表（通常）很糟糕。 Javier 2009-06-04T12:41:44+08:002009-06-04T12:41:44+08:00 ext3 文件系统在大多数发行版上默认都有用于大目录的 htree。做一个tune2fs -l /dev/sda1（或您正在使用的任何块设备）并检查“文件系统功能：”行。如果其中有一个“dir_index”，那么你就是黄金。 但是请注意，即使是最好的目录结构也只能快速找到一个特定文件。在一个巨大的目录上做ls会很糟糕，就像任何模式匹配一样，即使你知道它匹配单个文件。 由于这些原因，通常最好添加一层或两层目录。通常使用 ID 的一些位来命名目录。 KPWINC 2009-06-04T12:59:46+08:002009-06-04T12:59:46+08:00 它在某种程度上取决于您在 Linux 服务器上使用的文件系统。 假设您使用带有 dir_index 的 ext3，您应该能够非常快地搜索大型目录，因此速度应该不是什么大问题。列表（显然）将需要更长的时间。 至于您可以放入目录中的最大文件数，我很确定您可以可靠地处理多达 32,000 个文件。我不确定我是否想超过这个（即使你可能可以）。
如果您使用的是 ext3，我发现了这句话（警告：西班牙语网站）
进一步阅读表明 ext3没有32K 的限制，这可以通过经验证明
但它确实有文件夹的 32K 文件夹限制，可以用
这个（没有根据的）声称说
来自姊妹网站 stackoverflow.com 的这个问题也可以提供帮助。
一般来说：
这很大程度上取决于您使用的文件系统。某些旧版本的 ext3 在这方面很糟糕，这就是 btrees 的产生方式。Reiser 在处理大量此类文件时性能要高得多。在过去，由于 GroupWise 的故障，我在 NetWare 服务器上有一个 Novell NSS 目录，其中包含 250,000 个 4kb 的文件，它工作得很好。枚举目录很麻烦，但是访问该目录中的特定文件的速度与您希望的一样快。就像 8 年前一样，我必须假设现代 Linux 文件系统可以沉着应对。
这取决于您使用的文件系统，而不是操作系统的 64 位。对于每个文件系统，都会有某个时刻，用于搜索目录的算法的大 O 成本会变得更好。
如果您可以将文件层次结构分解为两 (2) 层层次结构，您将看到更好的长期可扩展性。
Linux存储目录中的文件系统基本上有两种方式：
作为文件的平面列表。
作为数据结构（通常是 B+Tree 或相关数据结构）。
随着文件的添加，前者会逐渐变慢。后者没有。请注意， ls 可能仍然需要很长时间，因为它必须查找所有这些文件的 inode，目录条目仅包含文件名和 inode 编号。
Ext3 目录是平面列表，带有哈希树索引选项以加快处理速度。
XFS 使用 B+树。
但是对于这些文件系统中的任何一个，如果您执行 ls -l，它需要命中与文件一样多的 inode。对于名称查找（例如打开文件时），B+Tree 和类似的东西对于大型目录来说会快得多。
然而，目录层次结构使管理文件更容易，因此您可能需要考虑这种可能性。即使是单层目录，例如每个目录限制为 4000 个文件，也会使事情更容易管理。
如果您要超过几百张图片，请务必考虑两件事：
我建议使用 XFS，或者，如果不这样做，则使用 ReiserFS，将两层或三层深度的目录层次结构按两字节对划分。例如
这将在前几个级别为您提供 256 个目录，将图像拆分为总共 65535 个单独的目录（对于 100-200k 图像及更多图像来说绰绰有余）。它将使事情变得更快，更具可扩展性，并且也使以后的维护变得更加容易。
ext3 的大多数默认配置限制每个目录有 32K 子目录（现在无法记住实际数量，但我们在几周前遇到了这个问题，当时系统是 Debian/Etch）。
在一些使用大量缓存的应用程序中也可能会打击你。
当然，考虑不使用 ext3。 http://kernelnewbies.org/Ext4#head-97cbed179e6bcc48e47e645e06b95205ea832a68 （显示 ext4 中的新功能）可能是一个有用的起点。
会说看看 squid 如何组织它的缓存（多层目录），因为一个目录中的许多文件可能很难维护。长列表（通常）很糟糕。
ext3 文件系统在大多数发行版上默认都有用于大目录的 htree。做一个
tune2fs -l /dev/sda1（或您正在使用的任何块设备）并检查“文件系统功能：”行。如果其中有一个“dir_index”，那么你就是黄金。但是请注意，即使是最好的目录结构也只能快速找到一个特定文件。在一个巨大的目录上做
ls会很糟糕，就像任何模式匹配一样，即使你知道它匹配单个文件。由于这些原因，通常最好添加一层或两层目录。通常使用 ID 的一些位来命名目录。
它在某种程度上取决于您在 Linux 服务器上使用的文件系统。
假设您使用带有 dir_index 的 ext3，您应该能够非常快地搜索大型目录，因此速度应该不是什么大问题。列表（显然）将需要更长的时间。
至于您可以放入目录中的最大文件数，我很确定您可以可靠地处理多达 32,000 个文件。我不确定我是否想超过这个（即使你可能可以）。