Neil Brown writes:
> On Wednesday August 15, [EMAIL PROTECTED] wrote:
> >
> > 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)
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
