On Wed, 28 Apr 2010 04:02:39 +0200 (CEST)
Mikael Abrahamsson <swmike@swm.pp.se> wrote:
quoted text > On Wed, 28 Apr 2010, Neil Brown wrote:
>
> >> I think I can see a problem here:
> >> You had 11 active devices over 12 when you received the read error.
> >> At 11 devices over 12 your array is singly-degraded and this should be
> >> enough for raid6 to recompute the block from parity and perform the
> >> rewrite, correcting the read-error, but instead MD declared that it's
> >> impossible to correct the error, and dropped one more device (going to
> >> doubly-degraded).
> >>
> >> I think this is an MD bug, and I think I know where it is:
> >>
> >>
> >> --- linux-2.6.33-vanilla/drivers/md/raid5.c 2010-02-24
> >> 19:52:17.000000000 +0100
> >> +++ linux-2.6.33/drivers/md/raid5.c 2010-04-27 23:58:31.000000000 +0200
> >> @@ -1526,7 +1526,7 @@ static void raid5_end_read_request(struc
> >>
> >> clear_bit(R5_UPTODATE, &sh->dev[i].flags);
> >> atomic_inc(&rdev->read_errors);
> >> - if (conf->mddev->degraded)
> >> + if (conf->mddev->degraded == conf->max_degraded)
> >> printk_rl(KERN_WARNING
> >> "raid5:%s: read error not correctable "
> >> "(sector %llu on %s).\n",
> >>
> >> ------------------------------------------------------
> >> (This is just compile-tested so try at your risk)
> >>
> >> I'd like to hear what Neil thinks of this...
> >
> > I think you've found a real bug - thanks.
> >
> > It would make the test '>=' rather than '==' as that is safer, otherwise I
> > agree.
> >
> >> - if (conf->mddev->degraded)
> >> + if (conf->mddev->degraded >= conf->max_degraded)
>
> If a raid6 device handling can reach this code path, could I also point
> out that the message says "raid5" and that this is confusing if it's
> referring to a degraded raid6?
>
You could....
There are lots of places that say "raid5" where it could apply to raid4
or raid6 as well. Maybe I should change them all to 'raid456'...
NeilBrown
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to
majordomo@vger.kernel.org
More majordomo info at
http://vger.kernel.org/majordomo-info.html