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


当前回答

不是答案,只是一些建议。

选择一个更合适的FS(文件系统)。因为从历史的角度来看,你们所有的问题都是足够明智的,在过去几十年里曾经是金融服务体系演变的核心。我的意思是更现代的FS更好地支持你的问题。首先从FS列表中做出一个基于你最终目的的比较决策表。

我认为是时候改变你的思维模式了。所以我个人建议使用分布式系统支持的FS,这意味着在大小、文件数量等方面没有任何限制。否则,你迟早会遇到意想不到的新问题。

我不确定这是否有效,但如果您没有提到一些实验,请尝试一下当前文件系统上的AUFS。我想它可以将多个文件夹模拟为单个虚拟文件夹。

为了克服硬件限制,可以使用RAID-0。

其他回答

完美的,

完美的,

完美无瑕:

(g.m. - rip)

function ff () { 
    d=$1; f=$2; 
    p=$( echo $f |sed "s/$d.*//; s,\(.\),&/,g; s,/$,," ); 
    echo $p/$f ; 
    }


ff _D_   09748abcGHJ_D_my_tagged_doc.json

0/9/7/4/8/a/b/c/G/H/J/09748abcGHJ_D_my_tagged_doc.json


ff -   gadsf12-my_car.json 

g/a/d/s/f/1/2/gadsf12-my_car.json

还有这个

ff _D_   0123456_D_my_tagged_doc.json

0/1/2/3/4/5/6/0123456_D_my_tagged_doc.json



ff .._D_   0123456_D_my_tagged_doc.json

0/1/2/3/4/0123456_D_my_tagged_doc.json

享受吧!

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

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

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

没有一个数字是“太多”的,只要它不超过操作系统的限制。然而,不管哪种操作系统,一个目录中的文件越多,访问任何单个文件所需的时间就越长,而且在大多数操作系统上,性能是非线性的,因此从10,000个文件中找到一个文件所需的时间是在1,000个文件中找到一个文件所需的时间的10倍以上。

与目录中有大量文件相关的次要问题包括通配符展开失败。为了降低风险,您可以考虑根据上传日期或其他有用的元数据对目录进行排序。

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

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

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

Ext3实际上有目录大小限制,它们取决于文件系统的块大小。没有每个目录的文件“最大数量”,而是每个目录的“用于存储文件条目的最大块数量”。具体来说,目录本身的大小不能超过高度为3的b-树,并且树的扇出取决于块大小。有关详细信息,请参见此链接。

https://www.mail-archive.com/cwelug@googlegroups.com/msg01944.html

我最近在一个格式化为2K块的文件系统上就遇到过这种情况,它莫名其妙地得到目录已满的内核消息警告:ext3_dx_add_entry:目录索引已满!当我从另一个ext3文件系统复制时。在我的例子中,一个只有480,000个文件的目录无法复制到目标。