>>>>> "Greg" == Greg Oster <oster@cs.usask.ca> writes:

    >> After simulating (raidctl -F) a disk failure of a 4 disk raid5
    >> (3 + 1 spare), the spare disk got in 'used_spare' state and the
    >> whole raid was still usable under the 'reconstructing' phase.
    >> Fine!
    >> 
    >> But what's the smooth way (== the system is still usable during
    >> that time) back? 'raidctl -B' did the job, but blocks the whole
    >> system for the complete copyback time!

    Greg> It blocks the filesystem(s) on the RAID set... Unfortunatly,
    Greg> this is a limitation of the copyback code.

As positive aspect copyback is about twice as fast as the
reconstructing way...

    >> Trying it with 'raidctl -R ...', while the spare is in use,
    >> reconstructed the formerly failed disk smoothly, but left the
    >> spare disk in 'used_spare' state.

    Greg> Hmm!! It really shouldn't be letting you do a 'raidctl -R'
    Greg> after you've already reconstructed to a spare... smells like
    Greg> a bug..

A reboot 'solved' this problem, but that's not the clean way for a
raid system, anyway! ;-)
-> send-pr?

So, copyback is the only (clean) way back from a used spare to the
normal raid disk on a running machine?

Markus.