> I'm inclined to say that you should either trust the clean bit, or
> you don't.  [...] If you can name reasons why there should be a
> periodic fsck, one could use those exact same reasons to argue that
> there _always_ should be an fsck.

Except that trust is one of those things that isn't always boolean.  I
mostly trust the clean bit - assuming the replacing-init bug has been
fixed, of course - but not completely.  I want to save time on most
reboots, so skipping the fscks if the filesystem is probably clean is a
good thing, but I don't entirely trust the clean bits.

Or, think of it this way: assume that (I believe that) for every hour
of uptime, there is a .1% chance that the filesystem will get corrupted
somehow.  Then assume also that i want to fsck as soon as there's a 10%
chance that the filesystem is corrupt.

Then I want to fsck after 105.3+ hours of uptime.

Or you can do operation count instead of uptime.  Or you can tweak the
numbers, depending on your degree of trust in the hardware and software
and your level of paranoia.

Of course, if you're really paranoid, you don't trust fsck.  I normally
do under NetBSD, but I had one very bad experience under SunOS with a
filesystem that fsck passed but panicked the kernel in short order when
used.

> Perhaps it is too black-and-white, but..

Essentially, yes, that's my opinion of it. :-)

> Actually, thinking about it, I can come up with a reason to not set
> the clean bit..  Suppose you [trust your hardware and software].  The
> only (?) way in which your filesystem would end up in a messed up
> state, is that some process directly opens the disk device and flips
> some bits.  So a reason not to set the clean bit when unmounting, is
> if, at any point in time, the device has been opened for writing.

You can't normally open the device for writing if it's mounted under
NetBSD (you have to be running with securelevel<1, which means either
single-user or insecure).  (This is't perfect; you can still open other
partitions that overlap the one in question.)

But the main question I have about this is: how does fsck get exempted
from this?  It opens the device for writing, after all.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu