目录中文件过多导致ls命令卡住

本文翻译自Large Directory Causes ls to Hang

你一定遇到过这种情况，在一个有几百万文件的目录中执行ls命令，ls就卡在那了，是吧？

用ls -1 -f命令可以立即显示出文件。如果你想删除当前目录中的所有文件，使用如下命令：

ls -1 -f | xargs rm

在清理大量不需要的文件后，会留下一个巨大稀疏的目录对象（directory object）。假如一个目录有300万个文件，除了这些文件占用空间外，目录对象本身也会占用超过100M的空间。

你也许想重建一个目录来回收那100M空间。但是，如果目录是/tmp，那就要小心了，只能在单用户模式下操作。

ls命令为什么会卡住？

默认情况下，ls命令会将输出排序。为了排序，ls命令先将所有文件的名称读入内存。当遇到一个非常大的目录时，它就在那里不断地读入文件名，并且内存占用越来越大，直到将所有文件一次性以字母数字顺序列出来。

而ls -1 -f命令并不执行排序操作，只是读取目录然后立即显示文件。

下面举个例子，有个目录，包含300万个文件，文件名称形如test_file_a_1, test_file_a_2, ..., test_file_a_3000000. 用Perl脚本以文件名中的数字编号顺序来创建这些文件。

可以用ls -1 -f命令立即列出头几个文件：

bash-4.2$ time ls -1 -f | head
.
..
test_file_a_2531963
test_file_a_467778
test_file_a_2677947
test_file_a_329896
test_file_a_835701
test_file_a_1266060
test_file_a_261887
test_file_a_311007

real    0m0.006s
user    0m0.000s
sys     0m0.008s

现在，去掉上面命令中的-1和-f标志，ls命令花了大约10000倍长的时间：

bash-4.2$ time /bin/ls | head
test_file_a_1
test_file_a_10
test_file_a_100
test_file_a_1000
test_file_a_10000
test_file_a_100000
test_file_a_1000000
test_file_a_1000001
test_file_a_1000002
test_file_a_1000003

real    0m57.880s
user    0m55.644s
sys     0m2.121s

除了变得更慢外，后者还占用了大量内存。当ls命令真正开始打印文件名的时候，它已经在内存中存储了300万个文件名，使用了大约507M内存。相反，ls -1 -f命令内存占用从未超过4.5M，少了100倍。

EXT3/EXT4文件系统的Bug？

遍历EXT3/4文件系统花这么长时间和这么多资源有时被认为是文件系统Bug。但是我个人认为，如果有Bug的话，那只能是遍历软件的Bug（比如，find命令、不带-1和-f标识的ls命令以及各种备份软件），而不是文件系统的Bug。

注意顺序

在上面的测试中还有一点蹊跷之处。ls命令将文件名按照字母数字顺序排好了序，但是ls -1 -f命令的输出是以什么顺序呢？看起来比较随机。头三个文件是test_file_a_2531963、test_file_a_467778和test_file_a_2677947。这个次序与文件创建时间、修改时间、inode编号或者其它顺序都不符合。那到底是怎么回事？

测试使用的是EXT4文件系统。EXT4和EXT3文件系统使用一种叫做HTree的哈希算法来存储文件名。当读取目录时，文件名是以任意顺序返回的。因此，ls -1 -f的输出结果看起来混在一起不是有序的。

EXT2文件系统的行为有时候像本文中所说的EXT3和EXT4一样（比如在Fedora 16系统上），有时又不是（比如在Red Hat 4系统上），而是按照文件创建时间返回文件。Solaris UFS文件系统也一样。

进程卡住？看看它在干什么

当ls -1 -f命令不可用时，可以用strace（Linux系统）或者truss（Solaris系统）命令来监视进程来发现有用信息。在我同事Neil Dixon使用strace来监视ls进程时，我才发现这一巧妙方法。在终端中执行：

cd verybigdir
ls -l > /dev/null

然后获取ls进程的PID，在另一个终端中监视它，就可以看到ls正在获取每个文件的元信息：

[root@saturn ~]# strace -p 3963 2>&1 | grep lstat
lstat64(“test_file_a_2433028″, {st_mode=S_IFREG|0664, st_size=0, …}) = 0
lstat64(“test_file_a_2047256″, {st_mode=S_IFREG|0664, st_size=0, …}) = 0
lstat64(“test_file_a_1201573″, {st_mode=S_IFREG|0664, st_size=0, …}) = 0

这样就能立即看到文件名了。如果你想删掉它们，将上述strace的输出重定向到AWK处理。

我猜同样的方法可以用于监视其它进程。有人用这个方法查看过备份进程，或者大型find/cpio任务，甚至cp的进展程度吗？