On Wed, Mar 25, 2009 at 03:10:42PM +, Tzafrir Cohen (tzaf...@cohens.org.il)
wrote:
> $ for i in `seq 400`; do echo something quite longer; done | xargs
> /bin/echo | wc
> 756 1200 9200
[...]
> So it's indeed not 4M processes, but still quite a few.
Even 756 is much less than
On 2009-03-25 18:50, Paul E Condon wrote:
Top post because it is OT, but related. Yesterday I had occasion to
remove some old data from my system. I had a backup copy, and the data
was all on a single partition. I could have simply rewritten the file
system with mke2fs, but I decided, instead, to
Top post because it is OT, but related. Yesterday I had occasion to
remove some old data from my system. I had a backup copy, and the data
was all on a single partition. I could have simply rewritten the file
system with mke2fs, but I decided, instead, to use rm -rf * at the top
level of the file s
On Wed, Mar 25, 2009 at 2:49 PM, Emanoil Kotsev wrote:
> Just curious - why would you use sort before deleting something?
You wouldn't, that was the point.
Someone was trying to turn that OFF for find; but find doesn't do
that, so there was nothing to turn off.
On the other hand, ls and the sh
Chris Davies wrote:
> Tzafrir Cohen wrote:
>> At this point I wanted to write "well, one thing you you can optimize
>> away is the sorting of the 4M files that find does. To disable it, use
>> -". But I could not find such an option.
>
> That's because find doesn't sort. It generates the files i
Tzafrir Cohen wrote:
> At this point I wanted to write "well, one thing you you can optimize
> away is the sorting of the 4M files that find does. To disable it, use -".
> But I could not find such an option.
That's because find doesn't sort. It generates the files in directory
entry order. Proof
On Wed, Mar 25, 2009 at 03:10:42PM +, Tzafrir Cohen wrote:
> On Wed, Mar 25, 2009 at 07:53:06AM -0500, Ron Johnson wrote:
> > On 2009-03-25 05:16, Tzafrir Cohen wrote:
> >>> Tapani Tarvainen schrieb:
> > kj wrote:
> >> Now, I've been running the usual find . -type f -exec rm {} \;
> >>>
On Wed, Mar 25, 2009 at 07:53:06AM -0500, Ron Johnson wrote:
> On 2009-03-25 05:16, Tzafrir Cohen wrote:
>> On Wed, Mar 25, 2009 at 10:19:37AM +0100, Rainer Kluge wrote:
>>> Tapani Tarvainen schrieb:
> kj wrote:
>> Now, I've been running the usual find . -type f -exec rm {} \;
>> but th
On 2009-03-25 05:16, Tzafrir Cohen wrote:
On Wed, Mar 25, 2009 at 10:19:37AM +0100, Rainer Kluge wrote:
Tapani Tarvainen schrieb:
kj wrote:
Now, I've been running the usual find . -type f -exec rm {} \;
but this is going at about 700,000 per day. Would simply doing an rm
-rf on the Maildir
Boyd Stephen Smith Jr. wrote:
In <49c93fd1.7040...@net153.net>, Sam Leon wrote:
Most everyone here is recommending just plain old rm -rf
I might add that once you start the rm process that you find the pid of
it and then lower its priority with renice so that away your whole
system won't be slo
On Wed, Mar 25, 2009 at 10:19:37AM +0100, Rainer Kluge wrote:
> Tapani Tarvainen schrieb:
> >> kj wrote:
> >
> >>> Now, I've been running the usual find . -type f -exec rm {} \;
> >>> but this is going at about 700,000 per day. Would simply doing an rm
> >>> -rf on the Maildir be quicker? Or i
Tapani Tarvainen schrieb:
>> kj wrote:
>
>>> Now, I've been running the usual find . -type f -exec rm {} \;
>>> but this is going at about 700,000 per day. Would simply doing an rm
>>> -rf on the Maildir be quicker? Or is there a better way?
>
> While rm -rf would certainly be quicker and is
> kj wrote:
>> Now, I've been running the usual find . -type f -exec rm {} \;
>> but this is going at about 700,000 per day. Would simply doing an rm
>> -rf on the Maildir be quicker? Or is there a better way?
While rm -rf would certainly be quicker and is obviously preferred
when you want t
In <49c93fd1.7040...@net153.net>, Sam Leon wrote:
>Most everyone here is recommending just plain old rm -rf
>
>I might add that once you start the rm process that you find the pid of
>it and then lower its priority with renice so that away your whole
>system won't be slowed down while it works.
Wh
kj wrote:
Hi guys,
This might seem like a stupid question, but I'm hoping there's a better
way.
I discovered a Maildir on my server with 4+ million mails in. The
result of a cronjob that runs every minute - this has been fixed.
Now, I've been running the usual find . -type f -exec rm {} \
Chris Dale wrote:
If you know the count, Pipe Viewer can give you a progress meter:
$ rm -frv dir | pv -l -s 400 > /dev/null
546k 0:00:02 [ 886/s ] [> ] 36% ETA 0:00:03
Echoing someone else's comment on another thread -- "I learned something
new, today."
I like
On Thu, 19 Mar 2009, Marc Shapiro wrote:
> jc wrote:
> >
> > rm -rf --verbose to see what is being done
>
> I know that the OP was interested in some indication of progress, but I
> also know that I would not want to watch 4 million file names scroll
> across the terminal. Also, displaying tha
Paul E Condon wrote:
OP's last post was two (2) days ago. Are we beating a dead horse here? ;-0
Isn't that one of the things that we excel in on this list.
--
Marc Shapiro
mshapiro...@yahoo.com
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe"
jc wrote:
rm -rf --verbose to see what is being done
I know that the OP was interested in some indication of progress, but I
also know that I would not want to watch 4 million file names scroll
across the terminal. Also, displaying that much output is going to slow
the job down and make it
On 2009-03-20_10:13:50, Richard Hector wrote:
> On Thu, 2009-03-19 at 14:03 -0400, Miles Fidelman wrote:
> > jc wrote:
> > >
> > > rm -rf --verbose to see what is being done
> > >
> > >
> > yeah, but that can slow things up tremendously - whatever is being
> > written to becomes a bottleneck
>
On Thu, 2009-03-19 at 14:03 -0400, Miles Fidelman wrote:
> jc wrote:
> >
> > rm -rf --verbose to see what is being done
> >
> >
> yeah, but that can slow things up tremendously - whatever is being
> written to becomes a bottleneck
>
> you might try:
>
> rm -rf --verbose >some_file
>
> that w
jc wrote:
rm -rf --verbose to see what is being done
yeah, but that can slow things up tremendously - whatever is being
written to becomes a bottleneck
you might try:
rm -rf --verbose >some_file
that would run a lot faster and you can always cat the file to see
what's going on (or tail
> -Original Message-
> From: Paul E Condon [mailto:pecon...@mesanetworks.net]
> Sent: Thursday, March 19, 2009 10:39 AM
> To: debian-user@lists.debian.org
> Subject: Re: Delete 4 million files
>
> On 2009-03-19_12:07:11, Stefan Monnier wrote:
> > I'm c
On 2009-03-19_12:07:11, Stefan Monnier wrote:
> I'm curious: where did people come up with the incongruous idea of using
> find/rsync/younameit rather than just use plain old `rm'?
I think OP got the idea from a co-worker at his place of work before
his first post, but I'm not sure. When one uses
On Thu, Mar 19, 2009 at 12:07:11PM -0400, Stefan Monnier wrote:
> I'm curious: where did people come up with the incongruous idea of using
> find/rsync/younameit rather than just use plain old `rm'?
It seemed like the OP could use a pocketful of general un*x
"how standard tools work together". Ma
I'm curious: where did people come up with the incongruous idea of using
find/rsync/younameit rather than just use plain old `rm'?
Stefan
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
On 2009-03-19_01:56:26, Hal Vaughan wrote:
>
> On Mar 19, 2009, at 1:38 AM, Paul E Condon wrote:
>
>> On 2009-03-18_16:37:53, kj wrote:
>>> Hi guys,
>>>
>>> This might seem like a stupid question, but I'm hoping there's a
>>> better way.
>>>
...
>> running 'df' when you are curious about how mu
On Mar 19, 2009, at 1:38 AM, Paul E Condon wrote:
> Create a path, on the same disk to a place called 'hide', and
> mv /bar/foo /hide
> rm -rf /hide/foo &
This is excellent practical advice. (I tend to mv /bar/foo
/bar/too.DELETEME and then delete that, but the principle's the same as
long as you
Hal Vaughan wrote:
> On Mar 19, 2009, at 1:38 AM, Paul E Condon wrote
>> On 2009-03-18_16:37:53, kj wrote:
>>
>> Better than the "rm" command, above, I suggest:
>>
>> Create a path, on the same disk to a place called 'hide', and
>> mv /bar/foo /hide
>> rm -rf /hide/foo &
>>
>> This moves the j
On Thu, Mar 19, 2009 at 00:37, kj
wrote:
> Hi guys,
>
> This might seem like a stupid question, but I'm hoping there's a better way.
>
> I discovered a Maildir on my server with 4+ million mails in. The result of
> a cronjob that runs every minute - this has been fixed.
>
> Now, I've been running
On Mar 19, 2009, at 1:38 AM, Paul E Condon wrote:
On 2009-03-18_16:37:53, kj wrote:
Hi guys,
This might seem like a stupid question, but I'm hoping there's a
better way.
I discovered a Maildir on my server with 4+ million mails in. The
result
of a cronjob that runs every minute - this
On 2009-03-18_16:37:53, kj wrote:
> Hi guys,
>
> This might seem like a stupid question, but I'm hoping there's a better way.
>
> I discovered a Maildir on my server with 4+ million mails in. The result
> of a cronjob that runs every minute - this has been fixed.
>
> Now, I've been running the us
On Wed, Mar 18, 2009 at 10:05:08PM +0100, Jörg-Volker Peetz wrote:
> kj wrote:
> > Now, I've been running the usual find . -type f -exec rm {} \;
> > but this is going at about 700,000 per day. Would simply doing an rm
> > -rf on the Maildir be quicker? Or is there a better way?
>
> As already s
2009/3/18 Jörg-Volker Peetz :
> kj wrote:
>>
>> Now, I've been running the usual find . -type f -exec rm {} \;
>> but this is going at about 700,000 per day. Would simply doing an rm
>> -rf on the Maildir be quicker? Or is there a better way?
worse reading
http://translate.google.com/translate?
kj wrote:
>
> Now, I've been running the usual find . -type f -exec rm {} \;
> but this is going at about 700,000 per day. Would simply doing an rm
> -rf on the Maildir be quicker? Or is there a better way?
As already said, this calls rm for every file. Another alternative is with newer
version
On Wed March 18 2009 09:37:53 kj wrote:
> This might seem like a stupid question, but I'm hoping there's a better
> way.
>
> I discovered a Maildir on my server with 4+ million mails in. The
> result of a cronjob that runs every minute - this has been fixed.
>
> Now, I've been running the usual fi
On Mar 18, 2009, at 1:53 PM, Rob Starling wrote:
On Wed, Mar 18, 2009 at 10:25:13AM -0700, Raquel wrote:
On Wed, 18 Mar 2009 16:37:53 +
kj wrote:
I discovered a Maildir on my server with 4+ million mails in. The
result of a cronjob that runs every minute - this has been fixed.
Now, I'v
Steve Kemp wrote:
That executes /bin/rm for each file group. YOu might find it
faster if you don't cause find to execute a /bin/rm command at all.
Instead try:
find . -type -f -delete
Steve
I learned something new today - thanks! rm -rf Maildir seems to be
faster though.
Tha
David A. Parker wrote:
kj wrote:
I'm pretty sure that deleting the entire directory with "rm -rf"
should be a lot faster.
- Dave
That's what I'm doing right now. I can't really tell if it's going any
faster (although it did start right away, so I'm probably saving some
time, at lea
On Wed, Mar 18, 2009 at 10:25:13AM -0700, Raquel wrote:
> On Wed, 18 Mar 2009 16:37:53 +
> kj wrote:
> > I discovered a Maildir on my server with 4+ million mails in. The
> > result of a cronjob that runs every minute - this has been fixed.
> >
> > Now, I've been running the usual find . -t
On Wed Mar 18, 2009 at 16:37:53 +, kj wrote:
> Now, I've been running the usual find . -type f -exec rm {} \;
> but this is going at about 700,000 per day. Would simply doing an rm
> -rf on the Maildir be quicker? Or is there a better way?
That executes /bin/rm for each file group. YOu
On Wed, 18 Mar 2009 16:37:53 +
kj wrote:
> Hi guys,
>
> This might seem like a stupid question, but I'm hoping there's a
> better way.
>
> I discovered a Maildir on my server with 4+ million mails in. The
> result of a cronjob that runs every minute - this has been fixed.
>
> Now, I've b
kj wrote:
Hi guys,
This might seem like a stupid question, but I'm hoping there's a better
way.
I discovered a Maildir on my server with 4+ million mails in. The
result of a cronjob that runs every minute - this has been fixed.
Now, I've been running the usual find . -type f -exec rm {} \
43 matches
Mail list logo
