On Sun, 20 Dec 2015 12:38:43 +0100 Edgar Fuß <e...@math.uni-bonn.de> wrote:
> I'm unsure what the "dev" argument to raidctl -B is: the spare or the > original? The 'dev' is the RAID device.... > Suppose I have a level 1 RAID with components A and B; B failed. I > add C as a hot spare (raidctl -a C) and reconstruct on it (raidctl -F > B) now I have A "optimal", B "spared" and C "used_spare". > Then I find that B's failure must have been a glitch; do I raidctl -B > B or raidctl -B C? So one note about the '-B' option.... IIRC, it actually blocks IO to the RAID set while the copyback is happening. I think the last time I looked at this I was of the opinion that the copyback bits should just be deprecated, as most people never use it, and it actually causes serious performance issues (i.e. no IO can be done to the set while copyback is in progress!). But it's been a while... > I suppose that after the copyback, I'll have A and B "optimal" and C > "spare", right? I believe that is correct... it's been a long while since I used copyback... > What if, during the reconstruction, I get an I/O error on B. I hope > the reconstruction will simply stop and leave me with A "optimal", B > "spared" and C "used_spare", right? Errors encountered during reconstruction are supposed to be gracefully handled. That is, if you have A and B in the RAID set, and B fails, and you encounter an error when reconstructing from A to C, then A will be left as optimal, B will still be failed, and C will still be a spare. C will not get marked as 'used_spare' (and be eligible to auto-configure as the second component) until the reconstruction is 100% successful. Later... Greg Oster
