>> So you have drives A, B, and C. A and B were live. Let's say B is >> the one that failed. You reconstructed onto C and have been running >> with A and C. > Yes.
>> Now you have a new B [...]. > Yes. >> So, you'd pull C, replace it with B > No. I don't pull C. I re-add B (I have lots of empty slots). Well, I meant "pull" in the sense of "remove from the RAID". Whether or not that means "disconnect from the system" is semi-irrelevant. But.... >> and initiate a reconstruct > No, a copyback (raidctl -B). This is an aspect of RAIDframe I don't know much about. I'm guessing here, but I would guess that this copies from C to B. In that case, for failures during the copyback.... If A fails, you have a copy on C, with no redundancy until the copy to B finishes. I don't know whether it is capable of realizing, after the copy is done, that it could run on B and C; unlike most RAID levels, for RAID 1 there's no reason in principle it couldn't - but I suspect that RAIDframe isn't set up to do so. If B fails, well, I assume you have to start the copyback over. If that's not the worst that happens, I would call it a major bug in RAIDframe. If C fails, you have to be running non-redundant, off A alone, because the copy to B isn't finished. In principle, it could finish copying from A instead, but I suspect it's not capable of switching mid-copyback. My guess is you have to reconstruct from A onto B. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML [email protected] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
