在一个目录中保存多少文件有关系吗?如果是,一个目录中有多少文件是太多的,拥有太多文件的影响是什么?(这是在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上,如果目录中有太多文件,shell可能无法展开通配符。我在Linux上托管的相册有这个问题。它将所有调整大小的图像存储在一个目录中。虽然文件系统可以处理许多文件,但shell不能。例子:

-shell-3.00$ ls A*
-shell: /bin/ls: Argument list too long

or

-shell-3.00$ chmod 644 *jpg
-shell: /bin/chmod: Argument list too long

这实际上取决于所使用的文件系统,以及一些标志。

例如,ext3可以有数千个文件;但在几千次之后,它就变得非常缓慢了。主要是在列出目录时,但也在打开单个文件时。几年前,它获得了“htree”选项,这极大地缩短了给定文件名获取inode所需的时间。

就我个人而言,我使用子目录将大多数级别保持在1000个左右的项目以下。在您的例子中,我将创建256个目录,使用ID的最后两个十六进制数字。使用最后一个数字,而不是第一个数字,这样可以实现负载平衡。

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

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

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

问题归结为你将如何处理这些文件。

在Windows下,对于我来说,在资源管理器中打开任何超过2k个文件的目录都比较缓慢。如果它们都是图像文件,在缩略图视图中,超过1k的文件往往打开得非常慢。

系统规定的上限曾一度是32767个。现在它更高了,但即使如此,在大多数情况下,一次处理的文件也太多了。

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

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.

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