Re: detecting read errors after RAID1 check operation

Neil Brown writes:

On Wednesday August 15, maccetta@laurelnetworks.com wrote:

quoted

There are already files like /sys/block/md_d0/md/dev-sdb/errors in /sys
which would be very convenient to consult but according to the kernel
driver implementation the error counts reported there are apparently
for corrected errors and not relevant for read errors during a "check"
operation.

When 'check' hits a read error, an attempt is made to 'correct' it by
over-writing with correct data.  This will either increase the
'errors' count or fail the drive completely.

What 'check' doesn't do (and 'repair' does) it react when it find that
successful reads of all drives (in a raid1) do not match.

So just use the 'errors' number - it is exactly what you want.

This happens in our old friend sync_request_write()?  I'm dealing with
simulated errors and will dig further to make sure that is not perturbing
the results but I don't see any 'errors' effect.  This is with our
patched 2.6.20 raid1.c.  The logic doesn't seem to be any different in
2.6.22 from what I can tell, though.

This fragment

	if (j < 0 || test_bit(MD_RECOVERY_CHECK, &mddev->recovery)) {
		sbio->bi_end_io = NULL;
		rdev_dec_pending(conf->mirrors[i].rdev, mddev);
	} else {
		/* fixup the bio for reuse */
		...
	}

looks suspicously like any correction attempt for 'check' is being
short-circuited to me, regardless of whether or not there was a read
error.  Actually, even if the rewrite was not being short-circuited,
I still don't see the path that would update 'corrected_errors' in this
case.  There are only two raid1.c sites that touch 'corrected_errors', one
is in fix_read_errors() and the other is later in sync_request_write().
With my limited understanding of how this all works, neither of these
paths would seem to apply here.
--
Mike Accetta

ECI Telecom Ltd.
Transport Networking Division, US (previously Laurel Networks)