[ Sorry for not replying earlier, but I was out of town... ]

> >>> Hmm, but I can't help but wonder if it would be better to but the
> >>> fstab goo into the wrapper, [...]
> >> I thought about that for quite a while. I finally decided that there
> >> was no good way to implement the -p (preen) option if we did things
> >> like that.

IMHO, there is no good way to implement the -p (preen) option in the backends
(see below). That's exactly the reason I didn't implement the fstab handling
code in fsck_msdos despite the fact, that this made life a bit harder for me
in administering my machines (just substituing "fsck -p" with
"fsck -p && fsck_msdos -p" would have made life a bit easier).

In fact, I think that implementing fstab handling code in all the backends
is a bug.

> > Uh, actually, it's pretty easy:
> 
> > 	change the per-fs '-p' option so that it does the single
> > 	(specified) file system.

Maybe more than one? Not sure here...

> > 	dispatch forks/execs of per-fs checkers as necessary
> 
> This has the additional advantage that the "run in parallel but avoid
> spindle contention" feature of fsck -p works even across filesystem
> types...which isn't really possible if you leave -p in the individual
> fsck_xxx binaries.

Yes, this is why I think -p can't be implemented reasonably in the backends.

> Of course, it has the downside that all fsck_xxx binaries must support
> -p, at least as a harmless no-op.  But then, they all have to take more
> or less the same argument pattern anyway for the dispatch thing to work
> right to start with.

Well, all our current backends (there are only fsck_ffs and fsck_msdos yet)
do support the -p option at least as, as Chris put it, "a quieter and
non-interactive version of the normal check which simply fails if there are
any errors".
--
ws@TooLs.DE     (Wolfgang Solfrank, TooLs GmbH) 	+49-228-985800