现在我在两台服务器上遇到了这个非常奇怪的问题，都运行CentOS5，都是ext4。 一个是SSD，另一个是普通硬盘，两个SATA都没有RAID。
问题是，当我在有大量子目录（> 1000）的目录上运行rm -r，其中每个子目录有大量文件（> 1000）时，这些目录驻留的磁盘将间歇性地locking。
这可以通过顶部看到。 通常情况下，rm命令的CPU占用率大约在50-60％之间，但是突然间会在10-15秒之间下降到零，然后再回到50-60％，持续3-4秒，然后再次下降到零。 在rm命令处于0％cpu的时候，即使是简单的命令，例如驱动器上的ls，也会挂起，直到rm再次以50-60％的速度运行为止。
当rm运行在0％时，我也得到0.0％wa。
正如你可以想象的那样，这个不断挂起的磁盘使处理非常缓慢。 我很犹豫要把它归咎于坏的磁盘上，因为我现在已经看到了这种行为在两个不同的系统上。
有人有什么想法吗？
编辑：也想指出，当rm运行在0.0％cpu时，jbd2 / sdc1-8仍然在有问题的磁盘上处于活动状态。
不是一个解决scheme，而是一个解决方法：你可以用ionice -c3启动rm。 如果你能重现这个问题，你可以用strace -tt -o rm.strace rm ...来跟踪它，然后联系ext4开发者。
首先，
在ssd文件系统上，您需要启用disgard选项。 例如
# mount -t ext4 -o discard /dev/ssd_dev /mnt/storage/location
你可以在这里阅读（RedHat SSD Tuning）
最后，您可能想要查看您的块大小作为硬驱动和SSD大小不同。 但是，如果你不想重新安装系统，那么我认为重新安装disgard选项应该做的伎俩。
更新：慢rm可以归因于文件系统写障碍， 这里解释
干杯，丹妮
删除数百万个文件会导致数百万笔交易。 这将很快填满期刊。 你看到的摊位是由期刊被冲刷造成的。
使用更大的期刊应该允许更多的交易在冲洗之前被批量化，所以你应该看到更less的这样的摊位。
默认的日志大小通常是128 MB。 您可以使用tune2fs -J size=512在干净卸载的fs上使日志大小增加四倍
我发现在使用recursion选项删除大量文件时，最好使用for循环来编写一个简单的bash脚本来逐个删除文件。 类似于：
for f in /path/to/dir/* do # if file, delete it [ -f "$f" ] && rm "$f" done