We're using rsnapshot for backups. It keeps lots of snapshots of the backuped up file, but it does delete old ones. This is good. However it's taking about 7 hours to do a rm -rf on a massive directory tree. The filesystem is XFS. I'm not sure how many files are there, but it numbers in the millions probably.

Is there anyway to speed it up? Is there any command that does the same as rm -rf and doesn't take hours and hours?

8 Answers
8

"rm -rf" does a recursive depth-first traversal of your filesystem, calling unlink() on every file. The two operations that cause the process to go slowly are opendir()/readdir() and unlink(). opendir() and readdir() are dependent on the number of files in the directory. unlink() is dependent on the size of the file being deleted. The only way to make this go quicker is to either reduce the size and numbers of files (which I suspect is not likely) or change the filesystem to one with better characteristics for those operations. I believe that XFS is good for unlink() on large file, but isn't so good for large directory structures. You might find that ext3+dirindex or reiserfs is quicker. I'm not sure how well JFS fares, but I'm sure there are plenty of benchmarks of different file system performance.

I agree with everything here apart from your statement that unlink speed being dependant on the size of the file. unlink just removes the link to the file and does nothing to the actual contents. There should be no discernable difference between files of different size (you can test this yourself).
–
Kamil KisielJan 28 '10 at 22:27

I think rsnapshot uses hard-links as part of the maintaining-multiple-snapshots-efficiently feature. So if the questioner is using that feature using separate filesystems won't work (as you can't hard-link over a filesystem boundary)
–
David SpillettJul 28 '09 at 10:10

That could work, since a mv is very very quick.
–
RoryJul 28 '09 at 10:15

Yup - it works well. I've used this technique many times to "fix" maildir-based mailboxes where an email client has lost it brain and left a mess on the disk. The biggest (single) directory I've fixed in this manner had around around 1.5 or 2 million files IIRC. Total downtime to the end user was ~3 minutes, most of which was waiting for the mail client and imap processes to die.
–
Greg WorkJul 28 '09 at 11:25

If you are doing the rm at effectively at the file level then it will take a long time. This is why block based snapshots are so good:).

You could try splitting the rm into separate areas and trying to do it in parallel however I might not expect it to make any improvement. XFS is known to have issues deleting files and if that is a large part of what you do then maybe a different file system for that would be an idea.

Block-based snapshots are not uniquely good in this case. A number of file systems---WAFL and ZFS come immediately to mind---also provide good performance for snapshot delete. They treat snapshots as first class file system objects. So rather than iterating (slowly) over millions of files to determine which blocks to free, they only have to look a the block-list associated with the snapshot.
–
Keith SmithJul 30 '09 at 1:03

Hmm. I probably came off as being too contrary above. The original poster must be using Linux, and there really isn't a well-proven Linux file system that does snapshots---although btrfs and nilfs look interesting for the future. So as a practical matter, I agree---better to use block-based snapshots.
–
Keith SmithJul 30 '09 at 1:30

+1 for the tip to split and parallelize the workload: xfs plays its strength on parallel workloads.
–
hurikhan77Sep 21 '09 at 21:38