Todd Vierling writes:
> On Mon, 15 Aug 2005, Greg Oster wrote:
> 
> > RAIDframe doesn't support automatically rebuilding to the hot
> > spare, so hot-adding the spare with 'raidctl -a' just before you need
> > to rebuild is typically sufficient... (If you have a script to do
> > automatic rebuilding in the event of an error, then you can add
> > the appropriate 'raidctl -a' command to that script...)
> 
> This is not too dissimilar from something I've been meaning to ask you:  Is
> it possible to *reconfigure* a RAID 1 component?  e.g.,
> 
> =====
> Components:
>            /dev/wd0h: optimal
>           component1: spared
> Spares:
>            /dev/wd1h: used_spare
> Component label for /dev/wd0h:
>    Row: 0, Column: 0, Num Rows: 1, Num Columns: 2
> [...]
> component1 status is: spared.  Skipping label.
> Component label for /dev/wd1h:
>    Row: 0, Column: 1, Num Rows: 1, Num Columns: 2
> [...]
> =====
> 
> Note "component1" -- the device actually appears to have that name in the
> RAID label.  Bizarre.  The reason it does, though, is not so bizarre;
> apparently the original component drive (/dev/wd1h at the time) failed
> during setup of the RAID set, making it not accessible when it came time to
> write the set label.
> 
> To add the swapped-in replacement, I had to add it as a spare and
> immediately fail to it.  This seems suboptimal, although it may well be
> running at the same speed as if it were directly configured. 

It does.  The problem is purely one of cosmetics.

> Is it possible
> to reconfigure easily to make /dev/wd1h the non-"spare" column-1 disk here,
> if only to make the set look more sane?

Not at this time.  It's one of the things on my TODO list, but the 
"right fix" requires gutting how components and spares are handled,
and that's a bit of a major undertaking...  A reboot will typically 
fix the cosmetic issue, and so it's never become a priority... 

Later...

Greg Oster