My toughest Linux foe yet (/bin/rm)

Who woulda thunk it? I have a new-in-the-last-year Linux box, large-ish disk (750GB), mostly one big ext3 filesystem, and -- OK, shoot me... -- a bunch of many-rsync'd-hard-links directories therein.

I made the disastrous choice to remove some of those directories, you know... /bin/rm -rf *.OLD.

Two weeks later, the job isn't finished.

The job probably would be finished if I had exclusive use of the machine. But the other users get stroppy when I render the machine useless to them with my exotic Power Tool, /bin/rm. The load average runs to 5, the CPU romps up to 98+% IO waiting, and the other users start calling my number. Not in a nice way.

I would have thought that removing files-and-folders was about the most settled/debugged/worked-out part of Linux. How naive I obviously am.

My situation, or one very like it, was discussed on the Linux kernel list: "Very poor ext3 write performance on big filesystems?" (Probably elsewhere, too.) You can read it for yourself.

The first thing I did was make a script rm-and-sleep; not rocket science:

#!/bin/sh
/bin/rm ${1+"$@"}
sleep 5

I can then run that with something like...

find . -type f -print | xargs -n 50 rm-and-sleep

... and be sure I am not eating all of the system all of the time. (Just seeing the script makes me want to weep... decades of computing progress, and we're doing this?)

One thing suggested in the discussion cited above is to remove things in inode order. I ended up using cut rather than awk in Chris Mason's script, giving:

find . \( \! -type d \) -printf "%i %p\n" \
| sort -n \
| cut -d ' ' -f 1 --complement \
| xargs -n 500 rm-and-sleep

Guff to deal with spaces-in-filenames and nice and so forth -- omitted for brevity.

Ugh. Ugh. Ugh.