Date: Thu, 12 Jan 2012 21:23:52 -0600 From: Stephen Montgomery-Smith <stephen@missouri.edu> To: Garrett Cooper <yanegomi@gmail.com> Cc: Andre Goree <andre@drenet.info>, Doug Barton <dougb@freebsd.org>, freebsd-stable@freebsd.org, Rob Clark <rpclark@tds.net> Subject: Re: GENERIC make buildkernel error / fails - posix_fadvise Message-ID: <4F0FA3C8.2020608@missouri.edu> In-Reply-To: <CAGH67wTFy_2JAGOX=VmUx2KRmFcRrv8aaE3H4EkiqcOxmk09Hw@mail.gmail.com> References: <20120111161110.4258969c.rpclark@tds.net> <CAN-pd=cPY=Eg1RintaBx6GAon3FsLm-X0h6yvSBxzq=EZ5ukbg@mail.gmail.com> <20120112200843.2a348d2f.rpclark@tds.net> <4F0F8E6F.8000909@FreeBSD.org> <CAGH67wTFy_2JAGOX=VmUx2KRmFcRrv8aaE3H4EkiqcOxmk09Hw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F0FA3C8.2020608>