Re: raidctl -B syntax

[Greg Oster <oster%cs.usask.ca@localhost>]

On Sun, 20 Dec 2015 12:38:43 +0100
Edgar Fuß <ef%math.uni-bonn.de@localhost> 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