Re: reducing the number of disks a RAID1 expects

["J. David Beutel" <jdb@getsu.com>]

Neil Brown wrote:
> 2.6.12 does support reducing the number of drives in a raid1, but it
>     will only remove drives from the end of the list. e.g. if the
>     state was
>
>       58604992 blocks [3/2] [UU_]
>
> then it would work.  But as it is
>
>       58604992 blocks [3/2] [_UU]
>
> it won't.  You could fail the last drive (hdc8) and then add it back
> in again.  This would move it to the first slot, but it would cause a
> full resync which is a bit of a waste.
>   

Thanks for your help!  That's the route I took.  It worked ([2/2] 
[UU]).  The only hiccup was that when I rebooted, hdd2 was back in the 
first slot by itself ([3/1] [U__]).  I guess there was some contention 
in discovery.  But all I had to do was physically remove hdd and the 
remaining two were back to [2/2] [UU].

> Since commit 6ea9c07c6c6d1c14d9757dd8470dc4c85bbe9f28 (about
> 2.6.13-rc4) raid1 will repack the devices to the start of the
> list when trying to change the number of devices.
>   

I couldn't find a newer kernel RPM for FC3, and I was nervous about 
building a new kernel myself and screwing up my system, so I went the 
slot rotate route instead.  It only took about 20 minutes to resync (a 
lot faster than trying to build a new kernel).

My main concern was that it would discover an unreadable sector while 
resyncing from the last remaining drive and I would lose the whole 
array.  (That didn't happen, though.)  I looked for some mdadm command 
to check the remaining drive before I failed the last one, to help avoid 
that worst case scenario, but couldn't find any.  Is there some way to 
do that, for future reference?

Cheers,
11011011