我在一个目录中保留多少个文件有关系吗？如果是这样，那么目录中有多少文件太多了，文件太多会有什么影响？（这是在Linux服务器上。）
背景：我有一个相册网站，并且每张上传的图像都被重命名为8位十六进制ID（例如a58f375c.jpg）。这是为了避免文件名冲突（例如，如果上传了许多“ IMG0001.JPG”文件）。原始文件名和任何有用的元数据都存储在数据库中。现在，在images目录中大约有1500个文件。这使得通过FTP或SSH客户端列出目录中的文件需要花费几秒钟的时间。但是我看不到有什么其他效果。特别是，对图像文件提供给用户的速度似乎没有任何影响。
我曾考虑过通过制作16个子目录（0-9和af）来减少图片数量。然后，根据文件名的第一个十六进制数字将图像移动到子目录中。但是我不确定是否有这样做的理由，除了偶尔通过FTP / SSH列出目录之外。
Answers:
我在一个ext3目录中有超过800万个文件。，以及该线程中讨论的大多数其他方法readdir()使用的libc 列出大型目录。findls
出现这种情况的原因ls和find速度很慢，因为一次readdir()只能读取32K目录条目，因此在慢速磁盘上，需要多次读取才能列出目录。有解决此速度问题的方法。我在以下位置写了一篇非常详细的文章：http : //www.olark.com/spw/2011/08/you-can-list-a-directory-with-8-million-files-but-not-with- ls /
取得的关键是：getdents()直接使用-http: //www.kernel.org/doc/man-pages/online/pages/man2/getdents.2.html，而不是基于libc的任何东西，readdir()因此您可以指定缓冲区从磁盘读取目录条目时的大小。
我有一个包含88,914个文件的目录。像您一样，它用于在Linux服务器上存储缩略图。
是的，通过FTP或php函数列出的文件比较慢，是的，但是在显示文件时也会降低性能。例如www.website.com/thumbdir/gh3hg4h2b4h234b3h2.jpg的等待时间为200-400毫秒。作为另一个网站上的比较，我在目录中大约有100个文件，等待约40毫秒后才显示图像。
我给出了这个答案，因为大多数人都已经写了目录搜索功能的执行方式，您不会在thumb文件夹上使用它-只是静态地显示文件，但是会对文件实际使用方式的性能感兴趣。
它在某种程度上取决于Linux服务器上使用的特定文件系统。如今，默认值为带有dir_index的ext3，这使得搜索大型目录变得非常快。
因此，除了您已经提到的速度之外，速度不应该成为问题，因为上市将需要更长的时间。
一个目录中的文件总数是有限制的。我似乎记得它肯定可以处理32000个文件。
dir_index。我的目录中有大约1700万个文件。答案是large_dir使用tune2fs 打开。
请记住，在Linux上，如果目录中包含太多文件，则外壳程序可能无法扩展通配符。我在Linux上托管的相册遇到此问题。它将所有调整大小的图像存储在一个目录中。虽然文件系统可以处理许多文件，但Shell无法。例：
-shell-3.00$ ls A*
-shell: /bin/ls: Argument list too long
要么
-shell-3.00$ chmod 644 *jpg
-shell: /bin/chmod: Argument list too long
exec实现。Shell通常可以很好地扩展通配符-调用exec具有这么多参数的函数会返回错误。
我正在研究类似的问题。我们有一个分层的目录结构，并使用图像ID作为文件名。例如，将的图片id=1234567放置在
..../45/67/1234567_<...>.jpg
使用最后4位数字确定文件的位置。
对于几千个图像，您可以使用一个一级的层次结构。我们的系统管理员建议在任何给定目录（ext3）中添加不超过数千个文件，以提高效率/备份/他想到的其他原因。
我只需要在ext4文件系统中创建一个目录，其中包含1,000,000个文件，然后通过Web服务器随机访问这些文件即可。我没有注意到访问超过（例如）那里只有10个文件的文件的任何溢价。
这与几年前的经验完全不同ntfs。
如果实现目录分区方案所花费的时间很少，那么我赞成这样做。首次调试涉及通过控制台操作10000文件目录的问题时，您会了解。
例如，F-Spot将照片文件存储为YYYY \ MM \ DD \ filename.ext，这意味着在手动操作〜20000张照片集时我必须处理的最大目录约为800个文件。这也使文件更易于从第三方应用程序浏览。永远不要以为您的软件是访问软件文件的唯一方法。
它实际上取决于所使用的文件系统以及一些标志。
例如，ext3可以有成千上万个文件。但是经过数千次之后，它过去的运行速度非常慢。通常在列出目录时，但在打开单个文件时。几年前，它获得了“ htree”选项，从而大大缩短了获得给定文件名的索引节点所需的时间。
就个人而言，我使用子目录将大多数级别保持在一千个左右。在您的情况下，我将创建256个目录，并使用ID的最后两个十六进制数字。使用最后一位而不是第一位，这样可以使负载平衡。
ext3实际上确实有目录大小限制，并且它们取决于文件系统的块大小。没有每个目录的“最大数量”的文件，而是每个目录的“用于存储文件条目的最大块的数量”。具体来说，目录本身的大小不能超过高度为3的b树，并且树的扇出取决于块大小。有关更多详细信息，请参见此链接。
https://www.mail-archive.com/cwelug@googlegroups.com/msg01944.html
最近，我在一个以2K块格式化的文件系统上被这个问题咬住了，warning: ext3_dx_add_entry: Directory index full!当我从另一个ext3文件系统复制时，该文件系统莫名其妙地得到了目录已满的内核消息。就我而言，只有480,000个文件的目录无法复制到目标位置。
上面大多数答案无法显示的是，原始问题没有“一刀切”的答案。
在当今的环境中，我们拥有由不同硬件和软件组成的大型企业集团-有些是32位的，有些是64位的，有些是最先进的，有些是经过实践检验的-可靠且永不改变。除此之外，还包括各种较旧和较新的硬件，较旧和较新的OS，不同的供应商（Windows，Unix，Apple等）以及许多实用程序和服务器。随着硬件的改进以及软件已转换为64位兼容性，在使这个非常大而复杂的世界中的所有部分都能够顺应快速变化的步伐时，必须要有相当大的延迟。
恕我直言，没有一种方法可以解决问题。解决方案是研究可能性，然后通过反复试验找到最适合您特定需求的方法。每个用户都必须确定哪种方法适用于他们的系统，而不是使用Cookie切割器方法。
例如，我有一台带有几个非常大文件的媒体服务器。结果只有大约400个文件填充3 TB驱动器。仅使用了1％的inode，但使用了总空间的95％。拥有很多较小文件的其他人可能会在索引节点接近填充空间之前用尽它们。（通常，在ext4文件系统上，每个文件/目录使用1个inode。）虽然理论上目录中可能包含的文件总数几乎是无限的，但实用性决定了整体使用率决定了实际单位，而不是只是文件系统功能。
我希望上述所有不同的答案能促进思想和问题的解决，而不是为进步提出不可逾越的障碍。
“取决于文件系统”
一些用户提到性能影响取决于所使用的文件系统。当然。像EXT3这样的文件系统可能非常慢。但是，即使你使用EXT4或者XFS你不能阻止通过上市文件夹ls或find或通过像FTP外部连接会越来越慢的慢。
解决方案
我更喜欢使用@armandino的方法。为此，我在PHP中使用此小功能将ID转换为一个文件路径，每个目录可生成1000个文件：
function dynamic_path($int) {
// 1000 = 1000 files per dir
// 10000 = 10000 files per dir
// 2 = 100 dirs per dir
// 3 = 1000 dirs per dir
return implode('/', str_split(intval($int / 1000), 2)) . '/';
}
或者，如果您想使用字母数字字符，则可以使用第二个版本：
function dynamic_path2($str) {
// 26 alpha + 10 num + 3 special chars (._-) = 39 combinations
// -1 = 39^2 = 1521 files per dir
// -2 = 39^3 = 59319 files per dir (if every combination exists)
$left = substr($str, 0, -1);
return implode('/', str_split($left ? $left : $str[0], 2)) . '/';
}
结果：
<?php
$files = explode(',', '1.jpg,12.jpg,123.jpg,999.jpg,1000.jpg,1234.jpg,1999.jpg,2000.jpg,12345.jpg,123456.jpg,1234567.jpg,12345678.jpg,123456789.jpg');
foreach ($files as $file) {
echo dynamic_path(basename($file, '.jpg')) . $file . PHP_EOL;
}
?>
1/1.jpg
1/12.jpg
1/123.jpg
1/999.jpg
1/1000.jpg
2/1234.jpg
2/1999.jpg
2/2000.jpg
13/12345.jpg
12/4/123456.jpg
12/35/1234567.jpg
12/34/6/12345678.jpg
12/34/57/123456789.jpg
<?php
$files = array_merge($files, explode(',', 'a.jpg,b.jpg,ab.jpg,abc.jpg,ddd.jpg,af_ff.jpg,abcd.jpg,akkk.jpg,bf.ff.jpg,abc-de.jpg,abcdef.jpg,abcdefg.jpg,abcdefgh.jpg,abcdefghi.jpg'));
foreach ($files as $file) {
echo dynamic_path2(basename($file, '.jpg')) . $file . PHP_EOL;
}
?>
1/1.jpg
1/12.jpg
12/123.jpg
99/999.jpg
10/0/1000.jpg
12/3/1234.jpg
19/9/1999.jpg
20/0/2000.jpg
12/34/12345.jpg
12/34/5/123456.jpg
12/34/56/1234567.jpg
12/34/56/7/12345678.jpg
12/34/56/78/123456789.jpg
a/a.jpg
b/b.jpg
a/ab.jpg
ab/abc.jpg
dd/ddd.jpg
af/_f/af_ff.jpg
ab/c/abcd.jpg
ak/k/akkk.jpg
bf/.f/bf.ff.jpg
ab/c-/d/abc-de.jpg
ab/cd/e/abcdef.jpg
ab/cd/ef/abcdefg.jpg
ab/cd/ef/g/abcdefgh.jpg
ab/cd/ef/gh/abcdefghi.jpg
如您所见$int-version版本，每个文件夹最多包含1000个文件和99个目录，其中包含1000个文件和99个目录...
但是请不要忘记，这会对许多目录造成相同的性能问题！
最后，您应该考虑如何减少文件总数。根据您的目标，您可以使用CSS Sprite组合多个小图像，例如化身，图标，表情符号等。或者，如果您使用许多小的非媒体文件，请考虑以JSON格式进行组合。以我为例，我有数千个小型缓存，最后我决定将它们组合成10个一包。
我遇到了类似的问题。我试图访问其中包含超过10,000个文件的目录。构建文件列表并在任何文件上运行任何类型的命令都花费了太长时间。
我想出了一些PHP脚本来为自己完成此操作，并试图找到一种防止它在浏览器中超时的方法。
以下是我为解决该问题而编写的php脚本。
它如何帮助某人