The more I think about this solution, the more it bothers me. As
Rogier pointed out, one problem is that people who think they've done
a clean shutdown (since the root filesystem unmount seems to complete
successfully) would see a totally unexpected "fsck" on their next
reboot. Obviously, this is part of the more general problem that the
remounting (or unmounting) process can't differentiate between a
successful and "nearly successful" remount. At least if a root
unmount fails, the user knows to expect problems on a reboot.
More philosophically, it bothers me that we're allowing a filesystem
to be remounted read-only when it may actually still be modified in
the near future (as when a process using a 0-nlink inode successfully
exits and the inode is freed). Even if there are other ways this can
currently happen, I think we should avoid it if possible.
In a nutshell, a successful read-only remount would seem to include an
implicit promise from the kernel that it's finished modifying the
filesystem. As a user, I'd expect---after remounting a filesystem
read-only---to be able to toggle the drive's hardware read-only flag,
take an image backup of the media, have "fsck" run cleanly, etc.
Does this make sense?
Kevin <buhr@stat.wisc.edu>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu