在一个目录中保存多少文件有关系吗?如果是,一个目录中有多少文件是太多的,拥有太多文件的影响是什么?(这是在Linux服务器上。)

Background: I have a photo album website, and every image uploaded is renamed to an 8-hex-digit id (say, a58f375c.jpg). This is to avoid filename conflicts (if lots of "IMG0001.JPG" files are uploaded, for example). The original filename and any useful metadata is stored in a database. Right now, I have somewhere around 1500 files in the images directory. This makes listing the files in the directory (through FTP or SSH client) take a few seconds. But I can't see that it has any effect other than that. In particular, there doesn't seem to be any impact on how quickly an image file is served to the user.

我想过通过创建16个子目录来减少图像的数量:0-9和a-f。然后我将根据文件名的第一个十六进制数字将图像移动到子目录中。但是除了偶尔通过FTP/SSH列出目录之外,我不确定这样做是否有任何理由。


当前回答

这在一定程度上取决于Linux服务器上使用的特定文件系统。现在默认是ext3和dir_index,这使得搜索大目录非常快。

所以速度不应该是一个问题,除了你已经注意到的问题,那就是上市需要更长的时间。

一个目录下的文件总数是有限制的。我记得它可以运行到32000个文件。

其他回答

这完全取决于文件系统。许多现代文件系统使用良好的数据结构来存储目录的内容,但旧的文件系统通常只是将条目添加到列表中,因此检索文件是一个O(n)操作。

即使文件系统做得正确,列出目录内容的程序仍然绝对有可能搞砸并执行O(n^2)排序,因此为了安全起见,我总是将每个目录的文件数量限制在不超过500个。

我有一个目录,里面有88914个文件。就像你自己,这是用于存储缩略图和在Linux服务器上。

通过FTP或php函数列出的文件是缓慢的,但是在显示文件时也有性能上的影响。例如,www.website.com/thumbdir/gh3hg4h2b4h234b3h2.jpg的等待时间为200-400毫秒。在另一个网站上,我有一个目录下大约100个文件,在大约40毫秒的等待后,图像就显示出来了。

我给出了这个答案,就像大多数人刚刚写了如何执行目录搜索函数一样,你不会在拇指文件夹上使用它——只是静态地显示文件,但会对如何实际使用文件的性能感兴趣。

上面的大多数答案都没有说明,对于最初的问题,没有“一刀切”的答案。

In today's environment we have a large conglomerate of different hardware and software -- some is 32 bit, some is 64 bit, some is cutting edge and some is tried and true - reliable and never changing. Added to that is a variety of older and newer hardware, older and newer OSes, different vendors (Windows, Unixes, Apple, etc.) and a myriad of utilities and servers that go along. As hardware has improved and software is converted to 64 bit compatibility, there has necessarily been considerable delay in getting all the pieces of this very large and complex world to play nicely with the rapid pace of changes.

恕我直言,没有一种方法可以解决问题。解决办法是研究各种可能性,然后通过反复试验找到最适合你特定需求的方法。每个用户必须确定什么适合他们的系统,而不是使用千篇一律的方法。

I for example have a media server with a few very large files. The result is only about 400 files filling a 3 TB drive. Only 1% of the inodes are used but 95% of the total space is used. Someone else, with a lot of smaller files may run out of inodes before they come near to filling the space. (On ext4 filesystems as a rule of thumb, 1 inode is used for each file/directory.) While theoretically the total number of files that may be contained within a directory is nearly infinite, practicality determines that the overall usage determine realistic units, not just filesystem capabilities.

我希望以上所有不同的答案都能促进思考和解决问题,而不是成为进步的不可逾越的障碍。

“取决于文件系统” 一些用户提到性能影响取决于所使用的文件系统。当然可以。像EXT3这样的文件系统可能非常慢。但是即使您使用EXT4或XFS,也不能防止通过ls或查找或通过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精灵组合多个小图像,如头像,图标,微笑等,或者如果你使用许多小的非媒体文件,考虑将它们组合在JSON格式。以我为例,我有数千个迷你缓存,最后我决定将它们组合成10个。

FAT32:

最大文件数:268,173,300 每个目录的最大文件数:216 - 1 (65,535) 最大文件大小:2 GiB - 1无LFS, 4 GiB - 1有

NTFS:

最大文件数:232 - 1 (4,294,967,295) 最大文件大小 实现:244 - 26字节(16 TiB - 64 KiB) 理论:264 - 26字节(16 EiB - 64 KiB) 最大卷大小 实现:232 - 1个集群(256tib - 64kib) 理论:264 - 1个集群(1 YiB - 64 KiB)

ext2:

最大文件数:1018 每个目录的最大文件数:~1.3 × 1020(性能问题超过10,000) 最大文件大小 16gib(每块大小为1kib) 256gib(区块大小为2kib) 2 TiB(区块大小4 KiB) 2 TiB(块大小为8 KiB) 最大卷大小 4 TiB(区块大小为1kib) 8 TiB(区块大小为2 KiB) 16 TiB(区块大小为4 KiB) 32 TiB(块大小为8 KiB)

ext3:

最大文件数:min(volumeSize / 213, numberOfBlocks) 最大文件大小:与ext2相同 最大卷大小:与ext2相同

ext4:

最大文件数:232 - 1 (4,294,967,295) 每个目录的最大文件数:无限制 最大文件大小:244 - 1字节(16tib - 1) 最大卷大小:248 - 1字节(256tib - 1)