Re: RAIDframe nested autoconfiguration

> I've enhanced RAIDframe autoconfiguration to handle RAID sets having
> components contained within other RAID sets (as, for example, in the
> "RAID on RAID" section of raidctl(8)). This, in particular, allows
> mounting the root filesystem from a multi-layered RAID.
Oh, excellent! I'm going to have to try to apply this to 4.0.1 on a
machine at work, where currently the second layer of raids are done
with raid*.conf files.
In passing, is there a way to boot with raid autoconfiguration
suppressed? I had a case I had to patch up manually where I swapped
out a failed drive for a cold spare - only the cold spare had been used
before and had RAIDframe data on it, and (because it was found earlier)
autoconfigured as its old unit number, pushing the disk that now had
that unit number out to another unit. I would have liked to boot
without raidframe autoconfig so I could destroy the data on that disk
before it caused trouble. (I suspected it might be there, so I was
prepared, which made it easier to deal with - but still annoying.)
> My changes also handle cases where some of the nodes in the RAID tree
> must be brought up in degraded mode (e.g., if one leaf disk goes
> missing from a striped mirror or striped parity arrangement),
Hmm. raid0 = sd0e, sd1e, missing; raid1 = sd2e, sd3e, raid0e; can
raid1e then fill out the missing member of raid0? (I haven't tried
setting such a horror up manually; it may be there are checks that
prevent it...and I'm not sure using it wouldn't promptly blow out the
kernel stack anyway.)
Obviously it would take a rather twisted sysadmin to deliberately set
such a thing up, but something like my replacement disk scenario above
could perhaps lead to such a thing accidentally. (The scenario I
described is not hypothetical, but its leading to this kind of tangled
hierarchy is.)
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B