On 01/12/2012 09:11 PM, Garrett Cooper wrote:
+1. And it's faster yet when you can run parallel copies of rm on
different portions of the directory tree (e.g. xargs, find [..] -exec)
as rm is O(n).
I have always wondered about that! I thought that the main bottleneck
in "rm -r" might be deleting directories which are not in the disk
cache, which then have to be copied from the disk. Copying two
different parts of the disk into cache - well it has to be done one at a
time whether the jobs asking for the copy of the disk are going
concurrently or consecutively.
And perhaps two instances of "rm -r" acting on different parts of the
hard drive will cause disk thrashing, so that they might even slow each
other down.
But this is all guess work on my part.
If I am wrong, and "rm -r" does work faster when working in parallel on
different parts, then why doesn't someone write the "rm" command to fork
copies of itself that work on different parts of large trees?
Stephen
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
