Date: Sat, 11 Feb 2012 10:17:50 -0500 From: Daniel Staal <DStaal@usa.net> To: freebsd-questions@freebsd.org Subject: Re: 'rm' Can not delete files Message-ID: <2447CE4E015EBEA182A15517@mac-pro.magehandbook.com> In-Reply-To: <4F3544DA.8010003@infracaninophile.co.uk> References: <1237723287.20120207235924@yandex.ru> <4F31A260.20109@infracaninophile.co.uk> <20120207231716.31aa8bc3@gumby.homeunix.com> <20120209032544.GA58560@ozzmosis.com> <CAE7N2kdmbm_5=c8oNknYQE5HOrvVjtfS4XTGYvxTjEQVbGr-7Q@mail.gmail.com> <4F353D1F.3020100@herveybayaustralia.com.au> <CAB%2B9ogewck4LU9wPtE4hWtT03ZoRBhYz3p-43WHkMcLoiX3Ahg@mail.gmail.com> <4F3544DA.8010003@infracaninophile.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
--As of February 10, 2012 4:24:58 PM +0000, Matthew Seaman is alleged to have said: > On 10/02/2012 16:04, Matthew Story wrote: >> find . -type f -depth 1 -print0 | xargs -n99 -0 -s8192 -c5 rm -- >> >> or some such, depending on your needs, I believe in most situations this >> particular invocation will also out-perform find ... -delete. > > Why would you believe that? find ... -delete calls unlink(2) directly on > each file it finds as it searches the directory tree given that it > matches the other find predicates. > > Whereas find ... -print0 | xargs ... rm ... involves a whole complicated > sequence of find doing the same searching and matching job, then > marshalling lists of filenames, piping them between processes, then > xargs exec(2)ing rm with chunks of that arglist; each rm invocation then > finally ... calling unlink(2) on each of the named files. On the other hand, passing it through xargs makes the deletion multi-threaded (well, multi-process), while using -delete keeps it all in one process. Depending on your execution environment, that may be a win. > Actually, I doubt you'ld see much difference above the noise in the > speed of either of those two commands: they're both going to spend the > vast majority of the time waiting for disk IO, and that's common to any > way of doing this job. This is likely the root of the issue however. ;) (There are probably some pathological cases of multi-processor, multi-controller, multi-disk systems where having multiple IO streams would make a difference, but they are likely to be few for something like this.) Daniel T. Staal --------------------------------------------------------------- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. ---------------------------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2447CE4E015EBEA182A15517>