Wendy Cheng wrote:
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).
Got some private emails in my folder... look like I didn't explain
things well... An unlinked inode is an inode that has been removed from
directory (so you would not be able to access it from operating system's
lookup routine). If you (as an application) need to access a file with
the same name, you would have to (re)create it (then gfs1 will assign a
new inode for that new file).
For this issue, the unlinked inode doesn't affect the correctness of the
filesystem operations. You can still safely use the filesystem, except
these orphan inodes will take extra disk space.
-- Wendy
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
