There still seems to be confusion on what I did. Let A and B be the two original components, C a spare (in the cupboard) and B' be B with the new firmware.
I start with A and B as the two components of a RAID-1. Now B failes. I have a degraded RAID with A alone. I plug in C, scsictl scsibus0 scan all all it, add it as a hot spare (raidctl -a C) and initiate a reconstruction (raidctl -F B). Now I'm redundant again with A and C. Since I didn't re-boot, RAIDframe knows that B has failed and C is a used spare. I now actually un-plug B, plug it into another machine, do some testing (verifying that it may reset on writes), install new firmware, do futher testing (verifying it now doesn't reset on writes) and am about to re-plug it into the orignal server (which won't notice it ever disappeared or that B has turned into B'---as far as this question is concerned, I could have done all this in the original server). What I'm now intending to do is to raidctl -B (with A, B' and C installed, of course). After that, I intend to raidctl -r C, then scscictl scsibius0 detach C and finally un-plug C and put it back into the cupboard again. My question was about 1. B', 2. C or 3. A failing during the copyback. > there was a crop of bad Seagate 500GB disks for a while and they had > a tendancy to fail in mass at the same time. My working hypothesis since some five years is that all Seagate discs are bad and bound to fail. We had a series of SATA 250G (the example above is about SAS 146K) drives that failed the same way (dozens of them), got most of them replaced on warranty and had the replacements failing the same way again.
