Does anyone know of a fast, safe way of deleting a large qtree on a NetApp? Has anyone tried the rc_toggle_basic command "rm" from the console? Will it remove files recursively? Do they go into snapshots? Is it a "good thing(tm)" to do?
It seems like a waste to do a "rm -rf" over NFS...
-- Jeff
-- ---------------------------------------------------------------------------- Jeff Krueger E-Mail: jeff@qualcomm.com NetApp File Server Lead Phone: 858-651-6709 IT Engineering and Support Fax: 858-651-6627 QUALCOMM, Incorporated Web: www.qualcomm.com
On Mon, Dec 13, 1999 at 07:13:12PM -0800, Jeff Krueger wrote:
Does anyone know of a fast, safe way of deleting a large qtree on a NetApp? Has anyone tried the rc_toggle_basic command "rm" from the console? Will it remove files recursively? Do they go into snapshots? Is it a "good thing(tm)" to do?
It seems like a waste to do a "rm -rf" over NFS...
A small perl script or C code calling ``unlink'' is probalby your best bet.
Can you publish one here ?
Eyal.
yann@ThePLAnet.net wrote:
On Mon, Dec 13, 1999 at 07:13:12PM -0800, Jeff Krueger wrote:
Does anyone know of a fast, safe way of deleting a large qtree on a NetApp? Has anyone tried the rc_toggle_basic command "rm" from the console? Will it remove files recursively? Do they go into snapshots? Is it a "good thing(tm)" to do?
It seems like a waste to do a "rm -rf" over NFS...
A small perl script or C code calling ``unlink'' is probalby your best bet.
-- Yann Golanski Internet Systems Developer PGP: www.kierun.org/pgp/key The Planet Online
Part 1.2Type: application/pgp-signature
On Tue, Dec 14, 1999 at 12:24:06PM +0200, Eyal Traitel wrote:
yann@ThePLAnet.net wrote:
A small perl script or C code calling ``unlink'' is probalby your best bet.
Can you publish one here ?
It is trivial!
===== cut here #/usr/bin/perl -w # main { $dir = "/some/dir/you/don't/want"; opendir(DIR, $dir) || die(" no such $dir"); while ( defined( $file = readdir(DIR) ) ) { if ( $file =~ /^.$/ || $file =~ /^..$/ ) { next; } unlink( $file ); } } ===== cut here
Will remove all the files in the directory called $dir. Please note that if you use this and fuck up then it's your own fault and yours alone.
1999-12-14-05:24:06 Eyal Traitel:
A small perl script or C code calling ``unlink'' is probalby your best bet.
Can you publish one here ?
How about
find DIR -depth -print0|perl -0 -lne '-d $_ ? rmdir : unlink'
or for an all-perl solution:
perl -MFile::Find -e 'finddepth(sub{-d $_?rmdir:unlink unless /^..$/},"DIR")'
-Bennett
And by the time all that is typed, or other proposed solutions are compiled, etc... a normal rm -rf Blah & would complete...
-Christopher
--4vu0d+lqoSa2/ZEk Content-Type: text/plain; charset=us-ascii
1999-12-14-05:24:06 Eyal Traitel:
A small perl script or C code calling ``unlink'' is probalby your best bet.
Can you publish one here ?
How about
find DIR -depth -print0|perl -0 -lne '-d $_ ? rmdir : unlink'
or for an all-perl solution:
perl -MFile::Find -e 'finddepth(sub{-d $_?rmdir:unlink unless /^..$/},"DIR")'
-Bennett
--4vu0d+lqoSa2/ZEk Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org
iD8DBQE4VnZWL6KAps40sTYRAdAAAJ4isViKZRKr/yWWx+r8xTAFIlhcWACdGv8U MMZrFlsBn7K9726TDQ3quLc= =eqXy -----END PGP SIGNATURE-----
--4vu0d+lqoSa2/ZEk--
In the immortal words of Chris Kotacka (arch@concentric.net):
And by the time all that is typed, or other proposed solutions are compiled, etc... a normal rm -rf Blah & would complete...
Not even _close_. rm -rf will take orders of magnitude longer than the perl solution, even if you type out the perl with one finger on a dvorak keyboard. Consult your local source code archive for clues as to why.
-n
------------------------------------------------------------memory@blank.org "Reality is that which, when you stop believing in it, doesn't go away." (PKD) http://www.blank.org/memory/------------------------------------------------
If I recall the original question and circumstances, this was not a filer on the verge of running into a major problem unless this guy got an answer fast... and I'm quite sure no mater how extensive the tree was/is that he was trying to remove would have been done by now using a normal rm -rf versus waiting for more than a day to get the "quickest" solution on the planet.
Sometimes people make problems more complicated than they need to be.
-Christopher
In the immortal words of Chris Kotacka (arch@concentric.net):
And by the time all that is typed, or other proposed solutions are compiled, etc... a normal rm -rf Blah & would complete...
Not even _close_. rm -rf will take orders of magnitude longer than the perl solution, even if you type out the perl with one finger on a dvorak keyboard. Consult your local source code archive for clues as to why.
-n
------------------------------------------------------------memory@blank.org "Reality is that which, when you stop believing in it, doesn't go away." (PKD) http://www.blank.org/memory/------------------------------------------------
On Tue, 14 Dec 1999, Chris Kotacka wrote:
If I recall the original question and circumstances, this was not a filer on the verge of running into a major problem unless this guy got an answer fast... and I'm quite sure no mater how extensive the tree was/is that he was trying to remove would have been done by now using a normal rm -rf versus waiting for more than a day to get the "quickest" solution on the planet.
Sometimes people make problems more complicated than they need to be.
He wasn't trying to remove anything as I recall. He asked what was the fastest way to remove files as rm -rf over NFS seemed like a waste. I would venture to say that he did an rm -rf on a pretty dense tree and saw the wonderful performance and load on the filer. Then he asked the question.
I, myself, once populated a filer with a tree, if I recall correctly, 100 deep from the top and 100 wide at every level. I then did an rm -rf and watched the filer top out at 100% utilization for several minutes. Needless to say, rm -rf on a large tree is a VERY expensive operation.
Tom
Does anyone know of a fast, safe way of deleting a large qtree on a NetApp? Has anyone tried the rc_toggle_basic command "rm" from the console? Will it remove files recursively? Do they go into snapshots? Is it a "good thing(tm)" to do?
I haven't managed to get the on-board "rm" to recurse into directories. But if anyone knows how to convince the box to do this, I'm all ears -- not knowing cost me downtime on a netcache a few days ago, grmp. :-/
It seems like a waste to do a "rm -rf" over NFS...
This depends on the scale of the problem. If the system isn't already busy, I've found that launching a few concurrent "rm -rf" processes scales pretty well. Alternatively, you could launch some find processes and pipe those into fastrm -- this probably isn't going to be noticeably faster, though.
Nick
-
Bennett Todd -
Chris Kotacka -
Eyal Traitel -
Jeff Krueger -
Nathan J. Mehl -
Nick Hilliard -
tkaczma＠gryf.net -
yann＠ThePLAnet.net