> > If it wasn't for the readonly issue, I'd say store the counts in the file
> > system ala /etc/dumpdates.  If fsck must be run in the absence of any
> > read/write filesystems, it does seem like the superblock is the only feasible
> > place to store the timestamp/count data.
> 
> While I agree in principle that the only feasible place to store the
> timestamp/count data is the superblock, there is a problem with this, if we
> plan to generalize the concept of fsck to other filesystems.
> 
> E.g., I've got a preliminary version of a fsck-like utility for msdosfs
> (written by Martin Husemann and myself). Since we cannot define any field in
> the msdosfs for our own purposes, we have to find a different solution for this
> filesystem, should we want to support clean bits there.

why is this a surprise, given that the implementation of 'cleanliness'
is (obviously) file system specific...  (e.g. the 'clean bit' is
stored in the FFS superblock...)

what should eventually happen is that 'fsck' simply frobs arguments
and the fstab, and invokes fsck_<fsname>, e.g. fsck_ffs, fsck_msdosfs,
etc., which should do the right thing on a per-file-system basis.


This basically means that a file system like msdosfs will either:
	(1) never be considered 'clean', or
	(2) require information about cleanliness to be stored
	    on another file system, for the use of the fsck
	    program.

Since you can't record whether a fs was properly unmounted, if it
doesn't support some in-filesystem 'clean' flag, i think (1) is
perfectly reasonable...


chris