In message <199601151604.LAA03877@Collatz.McRCIM.McGill.EDU>, der Mouse writes:
> > Consider the following fsck.conf:
> 
> > # FS		reboots	days
> > /dev/rsd0a	 *	 15
> > /dev/rsd0e	 10	  *
> > /dev/rsd1d	 20	 45
> 
> > where /etc/rc decides whether to fsck based on the minimum criteria
> > between # reboots or time-since-last-fsck.  We could use "* *" (or
> > simply not list the FS) to specify no forced periodic check.
> 
> That's perhaps a reasonable spec...but I don't see that it's got
> anything to do with modifying fsck.  You have to modify fsck, or else
> you have to _greatly_ complicate /etc/rc.  Currently, it just runs fsck
> with -p and lets fsck iterate over stuff in /etc/fstab.  To implement
> this scheme in /etc/rc (as opposed to fsck), you would have to make it
> iterate over fstab and fsck.conf in the shell script.  You would also
> have to figure out where to keep the counts; remember, the only
> filesystem mounted at that point is /, and it's readonly and might
> never go read/write.  (If fsck does it, the counts and/or times would
> be kept in the superblock, which in a sense is where they belong
> anyway.  But - unless you propose to add a separate tool for the
> purpose - the rc script has no access to counts in the superblocks.)

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.

In any case, fsck would have to be modified to compare this data with
the configuration file to determine when to do the full check.  We could
either add a specific flag for this or make it the default behavior when
fsck is invoked with no FS arguments.  In this way fsck is the only program
to either read or write the superblock counts and the rc command is kept
simple.