[Swift-devel] Re: 100 molecule

[Mihael Hategan]

Hmm. It never occurred to me, but that rm job could be batch=true.

On Tue, 2007-06-19 at 16:05 -0500, Mike Wilde wrote:
> One technique that works nice if you just want the old files out of 
> the way is to do an mv of the top level dir to a new name, and then 
> you can background the rm's.
> 
> - Mike
> 
> Yong Zhao wrote, On 6/19/2007 3:40 PM:
> > Ioan,
> > 
> > This sounds very good. I'm forwarding this to the swift list.
> > 
> > Yong.
> > 
> > On Tue, 19 Jun 2007, Ioan Raicu wrote:
> > 
> >> Yes, rm -rf could take that long... Yong, why don't you try a these two
> >> commands, instead of "rm -rf".... I bet it will be much faster on the
> >> GPFS at ANL!
> >>
> >> find ./ -exec rm {} \;
> >> find ./ -exec rm -r {} \;
> >>
> >> The first one removes the files, and the second one removes the
> >> directories... I found rm -rf to be very slow on the ANL GPFS.... it has
> >> to do with the fact that rm -rf does an expansion of all the files it
> >> needs to deletes... and it ends up being very very long if you hav many
> >> files to delete.... doing the method above, it does 1 delete at a
> >> time... so it doesn't suffer from the long list of files as rm -rf....
> >>
> >> Ioan
> >>
> >> Veronika Nefedova wrote:
> >>> I am wondering how the cleanup is done? Its hard to believe that "rm
> >>> -rf" would work that long. At the end of the successful run its just
> >>> one directory with one nested subdir had to be removed.
> >>>
> >>> NIka
> >>>
> > _______________________________________________
> > Swift-devel mailing list
> > Swift-devel at ci.uchicago.edu
> > http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel
> > 
> > 
>