Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!know!sdd.hp.com!uakari.primate.wisc.edu!ames!sgi!vjs@rhyolite.wpd.sgi.com
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.sys.sgi
Subject: Re: Dangling inode problem
Message-ID: <77257@sgi.sgi.com>
Date: 6 Dec 90 20:03:13 GMT
References: <1990Dec1.194910.9878@portia.Stanford.EDU> <1990Dec5.032329.5531@odin.corp.sgi.com>
Sender: guest@sgi.sgi.com
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 31

In article <1990Dec5.032329.5531@odin.corp.sgi.com>, bh@sgi.com (Bent Hagemark) writes:
> 
> Yes, fsck properly clears the reference, and yes nothing else can.
> The problem is that the directory entry refers to an inode which
> is deallocated.  The kernel EFS code can't even namei() this name much
> less unlink(2), open(2)...
> 
> The bug which creates such errant directory entries has been fixed and
> is available in The Next Release.


In 3.3.1 and 3.3.2 you can sometimes get bogus files in lost+found that you
cannot get rid of, and that fsck refuses to destroy.  Just this morning, a
couple of previously vital inodes in / were turned into such zombies on my
personnal workstation by a probably hardware failure in a VME network
board.  Similar problems have happened to sgi.sgi.com.

My solution is to use explosives.  Unlink the node (with unlink not rm),
clri the inode (having correctly determined the i-number and special device
name), and then reboot.  This morning, that did not work because the
mini-root kernel would hang trying to update the completely bogus inode, so
on the zillionth reboot, I clri'ed them and then pushed the reset button.

Please note that this sort of deletion is effective and NOT recommended.
A typo can leave you cursing while you look for backup tapes.

Fsck for The Next Release continues to be improved, so it might be able to
kill more such zombies.


Vernon Schryver,   vjs@sgi.com