一个未经充分测试的程序在 NFS 共享上创建了一个包含大量文件的目录，我需要将其删除。
ls -ald /home/foo
drwxrwxr-x 2 503 503 317582336 Jul 29 11:38 /home/foo
该目录位于 netapp 类型设备上约 600GB 的 NFS 挂载上。我实际上不知道其中有多少文件，但仅 10 分钟后创建的类似目录就有 121,000 个文件，因此可能在某个地方有数百万个文件。操作系统是 Linux 2.6 内核。
尝试找到一种方法来列出或删除它及其内容。 find /home/foo 导致 find 在大约 1 小时后死亡，除了“./”之外没有其他输出
答案1
（回答我自己的问题以防有人在搜索类似问题时发现它。）目录中可能有多达 900 万个文件。
不幸的是，无法直接登录服务器，它只是一个设备。文件系统的唯一访问方式是通过导出。
rm -rf 似乎不起作用。用 strace 观察它挂了。
查找无法完成，没有错误就终止了。
ls -1 似乎从未完成过。（我现在意识到它试图对结果进行排序，ls -1f 最终可能会起作用）。
起作用的只是一个简单的 perl 代码片段。我认为执行相同操作的 c 代码也会起作用。
opendir( my $dh, '/home/foo' ) or die $!
while ( my $file = readdir $dh ) {
print "$file\n";
}
答案2
我在 Google 上发现了这个相当老的话题，所以我想分享一些统计数据。
以下是三种从 NFS 服务器上删除文件的方法的比较：
- 普通 rm：
rm dir/* - 寻找：
find dir/ -type f -exec rm {} \; - 同步：
tempdir=$( mktemp -d ); \ rsync -a --delete $tempdir/ dir/; \ rmdir $tempdir
为了比较这些方法，我每次运行测试时都会创建 10000 个文件
for i in {1..10000} ; do touch $i ; done
图上的结果显示，rsync 速度更快，而 find 是三种方法中最慢的
当文件数量加倍时结果保持不变（我没有find对 20000 个文件进行运行），对 10000 个文件进行 3 次运行的平均时间，对 20000 个文件进行 2 次运行的平均时间。
10000 20000
find 28.3 -
rm 12.9 23.9
rsync 6.94 12.2
有趣的是看看这些方法的性能还取决于什么。
相关邮政该站点讨论了在 ext3 文件系统上删除大量文件。
答案3
我建议您不要尝试通过 NFS 删除这些文件——直接登录文件服务器并删除那里的文件。这样对 NFS 服务器（和客户端）的损害会小得多。
除此之外，使用 find（如 MattBianco 所述）或使用ls -1 | xargs rm -f（在该目录内），如果 find 无法完成（后者应该可以通过 NFS 正常工作，但我再次建议在本地执行）。
答案4
这似乎有点明显，但是你尝试过吗：
rm -rf /home/foo/
? 如果失败了，有没有办法可以使用正则表达式来获取足够小的子集来交给|xargs rm？
如果 ls 失败，您可以尝试echo /home/foo/* | xargs rm，但可能会失败并显示“行太长”或类似信息。哦，我赞同直接在服务器上而不是通过 NFS 执行此操作的建议。