Subject: Re: another RAIDframe oddity....
To: NetBSD Kernel Technical Discussion List <tech-kern@NetBSD.ORG>
From: Greg Oster <email@example.com>
Date: 11/01/2003 13:42:51
"Greg A. Woods" writes:
> [ On Sunday, October 19, 2003 at 15:13:37 (-0600), Greg Oster wrote: ]
> > Subject: Re: another RAIDframe oddity....
> > "Greg A. Woods" writes:
> > > BTW, is there any easy way to change the "Last configured as" value in
> > > the component labels?
> > Not easy.. no. (as in, no way to do it directly from raidctl)
> Hmmm.... another issue arose yesterday where this would also come into
> play, and where it's a lot less "cosmetic" than my initial situation.
> I had to move a RAID set from one host to another. Now since the drives
> were hot-swap I was able to move them without rebooting. However once I
> had them attached to the new system I had no way to autoconfigure them.
> Simply triggering autoconfiguration again, if there were a way to do it,
> would have caused a "collision" with the existing RAID set's device.
> I think it makes sense to consider supporting hot swap of whole RAID
> sets between systems.
If I can ever toss the old configuration code, the new configuration
code would do the trick -- just tell it what components are involved,
and it would figure out how they fit together. Things like "where
last configured" could be easily changed.
> I think this means that besides having some way
> to re-trigger the RAIDframe autoconfiguration procedures there also
> needs to be some way to manually inspect the on-disk component labels of
> arbitrary specified disks, and there needs to be some way to adjust the
> "last configured as" name in those labels so that a "new" RAID set can
> be brought safely on-line without a reboot. Of course already
> configured devices must be ignored when autoconfiguration runs too.
> There may be other issues, but that's what comes to mind initially.
As above, if the autoconfig code can be used for regular
configuration (i.e. 'raidctl -c' and 'raidctl -C') then this will
work. I had a stab at changing it a couple years ago, but the
various configuration bits are fiendishly interwoven, and successfully
removing the old config bits without killing the patient appeared
too difficult at the time...