Re: Fault tolerance with badblocks

On 8 May 2017, Anthony Youngman verbalised:

On 08/05/17 15:50, Nix wrote:

quoted

I wonder... scrubbing is not very useful with md, particularly with RAID
6, because it does no writes unless something mismatches, and on failure
there is no attempt to determine which of the N disks is bad and rewrite
its contents from the other devices (nor, as I understand it, does it
clearly say which drive gave the error, so even failing it out and
resyncing it is hard).

With redundant raid (and that doesn't include a two-disk, or even
three-disk mirror), it SHOULD recalculate the failed block. If it
doesn't bother even though it can, I'd call that a bug in scrub. What

It didn't, once upon a time (in 2010), and as far as I can tell from the
code it still doesn't.

I thought happened was that it reads a stripe direct from disk, and if
that failed it read the same stripe via the raid code, to get the raid
error correction to fire, and then it rewrote the stripe.

There's *failed*, which does trigger a rewrite, and there's 'we got a
mismatch', which on RAID-6 arguably should trigger a rewrite but instead
just tells you there was a mismatch, but not where, nor even on what
disk.

What would be a nice touch, is that if we have a massive timeout for
non-SCT drives, if the scrub has to wait more than, say, 10 seconds
for a read to succeed it then assumes the block is failing and
rewrites it.

What tends to happen is that the drive gets reset, which from md's
perspective is the drive vanishing and reappearing again. I don't see
any sane way for md to interpret *that* as anything but a possibly
rather major failure that should be reacted to by failing the drive out.
I mean, all it knows is there was a timeout: for all it knows there are
electrical problems there or something. The drive doesn't say (and
doesn't get a chance to say, because we reset it rather than wait five
minutes for it to tell us what's up).

             Actually, scrub that (groan... :-) - if the drive takes
longer than 1/3 of the timeout to respond, then the scrub assumes it's
dodgy and rewrites it.

It's hard to rewrite anything on a drive that's too busy failing a read
to do anything else.

-- 
NULL && (void)