[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Linux-cluster] Found unlinked inode

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]