Subject: Re: raidframe copyback blocks the whole system !?
To: Greg Oster <email@example.com>
From: Markus W Kilbinger <firstname.lastname@example.org>
Date: 06/26/2002 00:40:17
>>>>> "Greg" == Greg Oster <email@example.com> writes:
Greg> Well... if you have hot-swap drives, then you could just
Greg> stuff the new drive in place of the old one, and not worry
Greg> about doing a copyback.. (i.e. the new drive you put in
Greg> becomes the hot spare).
>> Hmm, how to come!? The old/new drive still has state 'failed',
>> the spare is 'used_spare'. So, what will happen if another
>> drive fails in this stage?
Greg> You stuff another drive into the box, hot-add it, and
Greg> rebuild to it :)
Let's proceed: ;-)
I just can place in a new drive in place of a failed one. -> A known,
but 'failed' scsi id / /dev/sd.. refers to a fresh drive now. ->
Adding this as a new spare ('raidctl -a /dev/sd..', I guess) would
work!? (I wouldn't even dare...)
>> How will the 'failed' drive become the new spare _without_
Greg> You stuff a fresh drive into that slot, and when a different
Greg> drive fails, rebuild to the fresh drive. Not quite the same
Greg> as a spare, but works much the same. :)
But then you've lost the real spare / redundancy effect, because then
the first reconstruction step (onto the spare drive), normally done
automatically, has to be done manually, now.
-> Then it would be better to handle the complete spare drives
manually, because there are only smooth reconstructions. Having a
'used_spare' means either blocking copyback or a (reordering) reboot.
Or is 'raidctl -C ...' allowed with a used running raid!? (Another
thing I wouldn't dare! ;-))