在一个巨大的目录树上执行rm -rf需要几个小时

我们正在使用rsnapshot进行备份。 它保留了备份文件的大量快照,但是它删除了旧文件。 这很好。 然而,在一个巨大的目录树上执行rm -rf大约需要7个小时。 文件系统是XFS。 我不确定有多less个文件,但是它的数字可能是数百万。

有反正加快吗? 有没有和rm -rf一样的命令,而且不需要几个小时?

没有。

rm -rf执行文件系统的recursion深度优先遍历,在每个文件上调用unlink() 。 导致进程缓慢的两个操作是opendir() / readdir()unlink()opendir()readdir()取决于目录中文件的数量。 unlink()取决于被删除文件的大小。 让这个更快的唯一方法是减less文件的大小和数量(我猜这是不太可能的),或者把文件系统更改为具有更好特性的文件系统。 我相信XFS对于大文件的unlink()是有用的,但是对于大的目录结构来说并不是那么好。 你可能会发现ext3 + dirindex或者reiserfs更快。 我不确定JFS的性能如何,但是我确定有很多不同的文件系统性能的基准。

编辑:看来, XFS是可怕的删除树 ,所以一定要改变你的文件系统。

或者,将目录移到一边,用相同的名称,权限和所有权重新创build目录,然后重新启动任何关心该目录的应用程序/服务。

然后,您可以在后台“很好地”原始目录,而无需担心延长的中断时间。

确保为XFS设置了正确的挂载选项。

使用-ologbufs = 8,使用XFS的logbsize = 256k可能会使您的删除性能提高三倍。

如果你在文件层面有效地进行了这个工作,那么这将需要很长时间。 这就是为什么基于块的快照是如此的好:)。

你可以尝试把rm分成不同的区域,并且试图平行的做,但是我可能不会期望它有任何改进。 已知XFS在删除文件方面存在问题,如果这是你所做的很大一部分,那么可能是一个不同的文件系统,这将是一个想法。

无论使用哪种文件系统,使用ionice进行IO密集型操作都是很好的select。
我build议这个命令:

  ionice -n7 nice rm -fr dir_name 

它将在IO负载较重的服务器上很好地进行后台操作。

我知道这是旧的,但我认为ID抛出一个build议。 您正在顺序删除这些文件,执行并行rm操作可能会加快速度。

http://savannah.nongnu.org/projects/parallel/ parallel通常可以用来代替xargs

所以如果你删除deltedir中的所有文件

 find -tf deletedir | parallel -j 10 rm 

这会让你只是空的目录结构删除。

注意:如上所述,您可能仍会遇到文件系统限制。

在这里可以select另一种方式来分离数据,这样就可以废弃并重build实际的文件系统,而不是去做RM?

如何减less命令的好处? 喜欢:

 nice -20 rm -rf /path/to/dir/