Hi,
Hereby an update of the results
> #! /bin/sh
> renice 5 $$
> while [ 1 ] ; do
> mv core_8286 core_8286.rm
> if [ $? -ne 0 ] ; then exit ; fi
> mv core_8286.rm/core_8286 .
> if [ $? -ne 0 ] ; then exit ; fi
> rmdir core_8286.rm
> if [ $? -ne 0 ] ; then exit ; fi
> done

Turned out te be a very interesting problem with a couple of ways to
solve it. Most strategies came up with starting from deepest level and
work your way up (that was also my first idea). I was very impressed and
surprised though by Mark's elegant simple linear script that starts from
the top (quoted above) and immediately starts working. I ran that on the
production server. It took very little cpu/mem. Took about 3 hours, but
I didn't mind that.
I had a total of 5 big trees to remove, so I could play around a bit
with the various suggestions. They were different in depth (from 50K to
over 100K) and I removed 4 of them now succesfully. Filesystem looks
consistent. Going down with "while cd core_pid" was easy (but be
carefull not to blow up cpu usage), but going up is more difficult.
Shell behaviour is indeed also different per shell. cd .. would give
path too long errors in some shells (sh or ksh) if you are deep enough.
Alternative was then going down to at least 50% of the depth and then
run a rm -r from there and once again from the top: took 10 minutes
removing and some hours descending for most trees. Am also testing the
Perl variants of Darran. Look correct and fast to me too (but take NUM
minus one instead of NUM for deletion of deepest dir first). Counting
the depth of a 74K tree took a few seconds!. Today I continue (if I have
some time), and will also compare HP with Solaris. Some key elements in
this problem are: avoid any commands that use system calls with full
path names, always use relative paths and use a linear approach. Thanks
so far for the suggestions; I was very happy to be able to stay online.
Btw the actual cause was a Oracle bug in 8, solved in Oracle 9i, time to
upgrade :-)
Regards, Gert

On Wed, 07 Jan 2004 10:46:20 +0100, GertK <gert.koopmanREMO@VETHISplanet.nl> wrote:
> Hi,
> Hereby an update of the results
>> #! /bin/sh
>> renice 5 $$
>> while [ 1 ] ; do
>> mv core_8286 core_8286.rm
>> if [ $? -ne 0 ] ; then exit ; fi
>> mv core_8286.rm/core_8286 .
>> if [ $? -ne 0 ] ; then exit ; fi
>> rmdir core_8286.rm
>> if [ $? -ne 0 ] ; then exit ; fi
>> done
>
> Turned out te be a very interesting problem with a couple of ways to
> solve it. Most strategies came up with starting from deepest level and
> work your way up (that was also my first idea). I was very impressed and
> surprised though by Mark's elegant simple linear script that starts from
> the top (quoted above) and immediately starts working. I ran that on the
> production server. It took very little cpu/mem. Took about 3 hours, but
> I didn't mind that.
> I had a total of 5 big trees to remove, so I could play around a bit
> with the various suggestions. They were different in depth (from 50K to
> over 100K) and I removed 4 of them now succesfully. Filesystem looks
> consistent. Going down with "while cd core_pid" was easy (but be
> carefull not to blow up cpu usage), but going up is more difficult.
> Shell behaviour is indeed also different per shell. cd .. would give
> path too long errors in some shells (sh or ksh) if you are deep enough.
> Alternative was then going down to at least 50% of the depth and then
> run a rm -r from there and once again from the top: took 10 minutes
> removing and some hours descending for most trees. Am also testing the
> Perl variants of Darran. Look correct and fast to me too (but take NUM
> minus one instead of NUM for deletion of deepest dir first). Counting
> the depth of a 74K tree took a few seconds!. Today I continue (if I have
> some time), and will also compare HP with Solaris. Some key elements in
> this problem are: avoid any commands that use system calls with full
> path names, always use relative paths and use a linear approach. Thanks
> so far for the suggestions; I was very happy to be able to stay online.
> Btw the actual cause was a Oracle bug in 8, solved in Oracle 9i, time to
> upgrade :-)
> Regards, Gert
>

Have you tried the unlink command? I don't know if HP has it, on Solaris it
is located in /usr/sbin The man page says it does no error checking. I am
not sure if it will also do a lot of chdirs, but it may be worth to try it.

Taco

Taco

"Taco R. de Vries" <tdvries@nospam.xs4all.nl> writes:

>Have you tried the unlink command? I don't know if HP has it, on Solaris it
>is located in /usr/sbin The man page says it does no error checking. I am
>not sure if it will also do a lot of chdirs, but it may be worth to try it.

unlink(2), as discussed before, I think, removes the directory entry
pointing to the toplevel directory. It then becomes unreferenced but
with a positive reference count; the next fsck will find and reconnect
it so not even one level of directory is removed but it's not relocated
in lost+found

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.