[Linux-cluster] Found unlinked inode

Wendy Cheng wcheng at redhat.com
Wed Sep 26 16:37:02 UTC 2007

David Teigland wrote:

>On Wed, Sep 26, 2007 at 05:40:59PM +0200, Borgstr??m Jonas wrote:
>>Hi again,
>>I was just able to reproduce the filesystem corruption again. This time
>>four lost zero-sized inodes were found :( And unfortunately
>>mounting+umounting the filesystem didn't make the lost inodes go away.
>>I still have a copy of the corrupted filesystem if there is any more
>>things you want me to test.
>I still think this is probably expected and cleaned up properly by gfs.
>When you mount you should see something like this:
>GFS: fsid=bull:x.2: jid=2: Trying to acquire journal lock...
>GFS: fsid=bull:x.2: jid=2: Looking at journal...
>GFS: fsid=bull:x.2: jid=2: Done
>GFS: fsid=bull:x.2: Scanning for log elements...
>GFS: fsid=bull:x.2: Found 48 unlinked inodes
>GFS: fsid=bull:x.2: Found quota changes for 0 IDs
>GFS: fsid=bull:x.2: Done

Just read this mail - not sure the running kernel version where this 
problem occurs . However, GFS1's unlinked inodes are linked into a list 
that are cleaned up by gfs_inoded (a daemon). So there is a time gap 
between the file is deleted and its on-disk inode is actually removed. 
There are two possibilities for this problem to occur:

1. An unclean shutdown where this linked list is not completely walked 
thru and cleaned up.
2. Possible bugs in RHEL5 based kernels (where gfs umount logic may 
accidentally overlook this clean-up logic).

In any case, I don't view this as a filesystem corruption - but the 
unlinked inodes would take some extra disk space that can only be 
cleaned up by fsck (and/or journal replay if the journal stil has the 
file remove transaction).

-- Wendy

More information about the Linux-cluster mailing list