我在一个ext3目录中有超过800万个文件。Libc readdir()， find, ls和本线程中讨论的大多数其他方法都使用它来列出大型目录。

ls和find在这种情况下很慢的原因是readdir()一次只读取32K的目录条目，所以在慢磁盘上需要很多很多次读取才能列出一个目录。这个速度问题有一个解决方案。我在http://www.olark.com/spw/2011/08/you-can-list-a-directory-with-8-million-files-but-not-with-ls/上写了一篇非常详细的文章

关键是:直接使用getdings()——http://www.kernel.org/doc/man-pages/online/pages/man2/getdents.2.html，而不是任何基于libc readdir()的方法，这样在从磁盘读取目录条目时就可以指定缓冲区大小。

请记住，在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

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

选择一个更合适的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

享受吧!

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

写了一篇文章。

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

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