[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: RAIDframe nested autoconfiguration
David Brownlee <abs%NetBSD.org@localhost> writes:
> I'm probably missing something (and not intending to denigrate
> the already better situation your patches have introduced :),
> but if the loop in step 5 was adjusted to encompass 6 as well
> (so after each configuration it checked for new components
> and looped back to 2 if any were found), *and* the loop went
> in strictly ascending raid id order, then the the 'raid1 using
> a degraded raid0 as a component' should work as expected?
Yes, if I just configure the one with the lowest unit number, then that
use case would work. I'm a little uneasy about having that kind of
silent dependency on numbering the RAIDs in a postorder-compatible way,
especially when it would manifest only in certain exceptional cases.
Granted, /etc/rc.d/raidframe also imposes that requirement, but it does
so unconditionally, and a shell script is somewhat easier to alter
locally than the kernel autoconfig code.
Alternatively, there's the option of trying to insert missing components
that turn up later; if this can be done without causing spurious
reconstructions, it might be preferable to the mild hackery I have
now[*]. I'd need to learn a bit more about the guts of RAIDframe to see
[*] Modulo the potential for infinite RAID cycles; but do other systems'
software RAID drivers attempt to check for that?
(let ((C call-with-current-continuation)) (apply (lambda (x y) (x y)) (map
((lambda (r) ((C C) (lambda (s) (r (lambda l (apply (s s) l)))))) (lambda
(f) (lambda (l) (if (null? l) C (lambda (k) (display (car l)) ((f (cdr l))
(C k))))))) '((#\J #\d #\D #\v #\s) (#\e #\space #\a #\i #\newline)))))
Main Index |
Thread Index |