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
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
