Greg Oster --> netbsd-help (2005-04-21 08:55:31 -0600):
[...]
> > > Shouldn't parity be checked (and possibly be rewritten) before filesystems
> > > are checked and mounted?
> 
> In theory, yes, but if you have a huge array that might take hours to 
> check, you probably don't want the unavailable for that long.  The 
> time it takes to do the check is the time your data is "unprotected" 
> against a component failure, so whether you want to be "live" during 
> is the question... 

I see. So what about a user-settable variable which determines whether
to run 'raidctl -P' in the background and thus to continue booting, or to
run it in the foreground and thus to wait until it returns?


> Note that if you are doing a fsck at the same time as doing a parity 
> check that they will be fighting against each other, and the fsck 
> will take much longer than normal to complete.  If we ever get a 
> filesystem that doesn't require a long fsck, then we'd certainly want 
> to move the parity check to make it occur as early as possible.

Hmm, to choose when to run the parity check seems not to be possible
with setting a variable... We'd probably need two different parity check
rc.d scripts.


> One fsck doesn't always find all the problems.  If you have a really 
> nasty crash, multiple "fsck -f"'s might be needed before fsck doesn't 
> find any further errors.  Just because you did one fsck doesn't mean 
> it fixed all the problem!  (I wouldn't go blaming RAIDframe if you 
> just did a single fsck after a nasty crash.)

Shouldn't /etc/rc.d/fsck handle this? That is, to run fsck up to
$fsck_max_runs times unless it succeeds?


Regards, Jukka

-- 
bashian roulette:
$ ((RANDOM%6)) || rm -rf ~