lkml.org 
[lkml]   [1998]   [Jun]   [27]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateFri, 26 Jun 1998 21:56:48 -0400
From"Theodore Y. Ts'o" <>
SubjectRe: 0-nlink inodes can lead to dirty filesystems being marked "clean"
   From: buhr@stat.wisc.edu (Kevin Buhr)
   Date: 	26 Jun 1998 13:36:50 -0500

   As far as I can see, the current semantics are as follows.  The
   filesystem on which the inode resides can be remounted read-only.  For
   "ext2", this means the filesystem will be marked "clean".  However,
   the 0-nlink inode and its blocks are still marked "in-use" in the
   bitmaps.  The filesystem will only *truly* be clean (i.e., not in need
   of an "fsck") if the process exits; then, the implied "iput" will
   deallocate the inode and its blocks in the associated bitmaps.

You're right.  This is not a disaster, as the filesystem is not invalid,
per se, but it does mean that the space isn't reclaimed until the next
fsck, which ideally should be soon.

    2.  When a filesystem is remounted read-only, it is *not* marked
	clean if it has in-use, 0-nlink inodes.  If a following "umount"
	or "remount" finds no such inodes, *then* the filesystem can be
	marked clean.

        Implementation would require changes in the VFS layer (to
        communicate to the "remount" functions that the filesystem is
        still dirty) and in various filesystem-specific functions,
        however.

This is certainly the cleaner solution, but it does require more work.
It doesn't have to require VFS layer changes, by the way; you can do
this by having the ext2 code bump a counter in the in-core ext2
superblock structure when it unlinks an inode, and decrement the counter
when ext2_free_inode actually frees the inode.  If that counter is
non-zero, then the ext2 filesystem knows that there must be in-use,
0-nlink inodes, and it can mark the filesystem dirty when it remounts it
r/o.

    3.  We refuse to remount a filesystem read-only if it has in-use,
	0-nlink inodes; that is, we have "fs_may_remount_ro" return 0 so
	that the remount request returns EBUSY.

This is certainly simpler, and easier to implement.  The one potential
danger with this is that since the filesystem isn't mounted read-only,
badly misbehaving init scripts might actually try to write files on the
root filesystem (which would normally fail), and then leave the
filesystem in a state which might require a manual e2fsck.  This would
arguably be a badly written init script, but it would be nice to be able
to avoid such a secnario.

Anyway, --- Kevin --- would you be willing to give a try at implementing
(2) using the implementation strategy I suggested?  If not, I'll be
happy to implement it myself, but given that you were the first to note
this problem, I thought I'd give you first crack at this alternative
fix, if you want.  (Otherwise I should have time to get to this sometime
next week.)

							- Ted

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 12:43    [from the cache]
©2003-2008