On 19 May 2017, NeilBrown said:
> On Tue, May 16 2017, Nix wrote:
>
>> On 16 May 2017, NeilBrown spake thusly:
>>
>>> Actually, I have another caveat. I don't think we want these messages
>>> during initial resync, or any resync. Only during a 'check' or
>>> 'repair'.
>>> So add a check for MD_RECOVERY_REQUESTED or maybe for
>>> sh->sectors >= conf->mddev->recovery_cp
>>
>> I completely agree, but it's already inside MD_RECOVERY_CHECK:
>>
>> if (test_bit(MD_RECOVERY_CHECK, &conf->mddev->recovery)) {
>> /* don't try to repair!! */
>> set_bit(STRIPE_INSYNC, &sh->state);
>> pr_warn_ratelimited("%s: mismatch sector in range "
>> "%llu-%llu\n", mdname(conf->mddev),
>> (unsigned long long) sh->sector,
>> (unsigned long long) sh->sector +
>> STRIPE_SECTORS);
>> } else {
>>
>> Doesn't that already mean that someone has explicitly triggered a check
>> action?
>
> Uhmm... yeah. I lose track of which flags me what exactly.
> You log messages aren't generated when 'repair' is used, only when
> 'check' is.
> I can see why you might have chosen that, but I wonder if it is best.
I'm not sure what the point is of being told when repair is used: hey,
there was an inconsistency here but there isn't any more! I suppose you
could still use it to see if the repair did the right thing. My problem
on that front was that I'm not sure what flag should be used to catch
repair but not resync etc: everywhere else in the code, repair is in an
unadorned else branch... is it the *lack* of MD_RECOVERY_CHECK and the
presence of, uh, something else?
--
NULL && (void)
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
