Chalk up another success story for the list! First of all, thanks to the
following for their replies:
- Ian MacPhedran <Ian_MacPhedran@engr.USask.Ca>
- Dan Simoes <dans@ans.net>
- Glenn Satchell - Uniq Professional Services <Glenn.Satchell@Uniq.com.au>
- ortlepp@dkrz.de (Ernst-Gunar Ortlepp)
- davem@fdgroup.co.uk (David Mitchell)
- patesa@aur.alcatel.com (Sanjay Patel)
- btirg@ui.uis.doleta.gov (Roland Grefer)
- sanjiv@aryabhat.cs.umsl.edu (Sanjiv K. Bhatia)
- Seth Rothenberg <SROTHENB@montefiore.org> (two replies!)
- Jim Harmon <jharmon@telecnnct.com>
Original Problem:
> Problem: there's a directory on one of our database servers that is not
> removable by conventional means (e.g. rm, find, etc). The contents of the
> directory, as far as I can tell, are sub-directories of the same name. A
> find command will bomb as follows <text deleted> ...
> Questions:
>
> 1) is there a way to remove this directory without having to shutdown the
> database, take the filesystem off-line and run something like "clri"?
>
> 2) if "clri" is the answer (as it was in a recent sun-managers summary), do
> I only need to give it the inode number of the "parent" directory? Will
> this be enough to free up all of the inodes associated with its
> sub-directories?
Most responses to question #1 suggested creative ways to "cd" down the
directory and, once the end is reached, start cd'ing up one directory at a
time removing the sub-directories. The example I followed was submitted by
David Mitchell:
#!/bin/sh
f=core_12649
while [ -d $f ]; do
cd $f
done
cd ..
while [ -d $f ]; do
rm -rf $f
cd ..
done
I was amazed that this would work since commands like find and pwd couldn't
handle the depth of this directory, but it worked beautifully! The only
change I made was to add a counter in each while loop to show how many
levels of recursion there were and to show status of the remove process.
There were over 1600 levels of recursion in this directory!
Most of the replies pertaining to question #2 suggested that the recursive
directories were using the same inode number and that clri and fsck would
work fine. Fortunately, I won't have to test this out.
Thanks for the help and for saving me from having to spend some time out of
normal working hours to try and fix this!
-- Christopher M. Murphy email: murphy@bms.com Bristol Myers Squibb phone: (609) 252-5741 Scientific Information Systems fax: (609) 252-6163 Princeton NJ
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:59 CDT