[Linux-cluster] Found unlinked inode

[Wendy Cheng]

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