[lug] file system frustration - the file that won't die?
crichey at gmail.com
Mon Apr 24 19:58:35 MDT 2006
On 4/24/06, Ken MacFerrin <lists at macferrin.com> wrote:
> Zan Lynx wrote:
> > On Mon, 2006-04-24 at 17:21 -0600, Ken MacFerrin wrote:
> >>This was all as superuser.. So according to "rm" it can't forcibly
> >>delete the parent directory because of this "block" file but according
> >>to "ls" and "file", the "block" file doesn't exist??
> >>lsof doesn't show this directory as being in use and I even tried to
> >>reboot to see if I could kill whatever was holding on to it, but no
> >>luck. Filesystem is ReiserFS under LVM2..
> > Sounds like a job for fsck! If it is your root partition you may need
> > to boot from a rescue CD or initrd / initramfs with ReiserFS fsck tools.
> > With ReiserFS you may be able to fsck a read-only mounted root
> > filesystem, but the ReiserFS tools make *no* guarantees that any file
> > access will work after fsck returns, since it may have completely
> > rewritten the tree.
> Yep.. that did it. I had to run --rebuild-tree to fix it but it seems
> all is well now. I just overlooked this completely since I hadn't had
> any recent crashes, hard reboots or heavy disk activity to corrupt it.
> I'm starting to loose faith in Reiserfs these days.. may be time to head
> back to XFS..
I'm glad you were successful. Just for future reference: another cause
of directories that can't be removed is this - I fell into this trap
at work. If you have done a 'chattr +i ....' on any files in the
directory, you won't be able to 'rm -rf' the directory until you have
done 'chattr -i ...' to fix the offending files.
Another fyi. Many have good luck with reiserfs, but all 3 of my
personal attempts to use reiserfs in the past led to fs corruption
after a power failure. Never again in this lifetime.
If you fill your heart with regrets of yesterday and the worries
of tomorrow, you have no today to be thankful for.
More information about the LUG