Subject: Re: new fsck(8)
To: None <tech-userlevel@NetBSD.ORG>
From: Wolfgang Solfrank <email@example.com>
Date: 09/14/1996 17:43:10
[ 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
ws@TooLs.DE (Wolfgang Solfrank, TooLs GmbH) +49-228-985800