Skip site navigation (1)Skip section navigation (2)
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+9ogewck4LU9wPtE4hWtT03ZoRBhYz3p-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: <http://docs.FreeBSD.org/cgi/mid.cgi?2447CE4E015EBEA182A15517>