在一个目录中保存多少文件有关系吗?如果是,一个目录中有多少文件是太多的,拥有太多文件的影响是什么?(这是在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列出目录之外,我不确定这样做是否有任何理由。


当前回答

不管怎样,我只是在ext4文件系统上创建了一个目录,其中有1,000,000个文件,然后通过web服务器随机访问这些文件。我没有注意到访问这些文件比(比如说)只有10个文件有任何溢价。

这与我几年前在ntfs上做这件事的经验完全不同。

其他回答

我现在正在研究一个类似的问题。我们有一个层次结构的目录结构,并使用映像id作为文件名。例如,其中放置了id=1234567的图像

..../45/67/1234567_<...>.jpg

使用最后4位数字来确定文件的位置。

对于几千张图像,您可以使用一级层次结构。出于效率/备份/其他考虑,系统管理员建议在任何给定目录(ext3)中不超过几千个文件。

我遇到的最大问题是在32位系统上。一旦你通过了一个特定的数字,像'ls'这样的工具就会停止工作。

一旦您通过了这个障碍,试图对该目录做任何事情都将成为一个巨大的问题。

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

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

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

我也有同样的问题。试图在ext4的Ubuntu服务器中存储数百万个文件。结束运行我自己的基准测试。发现平面目录执行得更好,同时使用起来更简单:

写了一篇文章。

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

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.

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