Thus spake Robert Elz ("RE> ") sometime Today...

RE> This kind of protection is not optional, the "file system clean" bit
RE> provides no real protection, and I certainly don't believe that "panic
RE> is the only option" is ever really the case (though it might be the
RE> only currently obvious option given the code structure in some
RE> places).

I disagree only slightly on the fsclean bit; it seems to me that if fsck
runs and successfully fixes the FS, fsclean ought to be set; otherwise
it's dirty.

However, I thought that a "fs_stable" bit would be nice; i.e.

	sync() flushes things out to disk.
	If anything is written to the disk, fs_stable gets cleared.
	If nothing is writen to the disk, fs_stable gets set.

"clean" should only get set if fsck fixes it or at umount time (and
then, only if the umount manages to clear everything out to the disk).

Whether this really gains anything, I don't know; it might even be
misleading, but I have never had a filesystem marked as "stable" go
bad on me.

It'd be nice after a crash for a FS marked as "stable" not to have to
undergo an fsck.

One neat feature of Lin...um, that other open source UNIX-alike-sort-of,
is that there is a timestamp on the mount such that at fsck time, if
a certain amount of time has elapsed between now() and the last mount,
regardless of state flags, fsck will check it anyway when run on it.

At least I thought it was neat.

				--*greywolf;
--
NetBSD: daemonic power.