From: NeilBrown <neilb@suse.com>
To: Nix <nix@esperi.org.uk>
Cc: Chris Murphy <lists@colorremedies.com>,
David Brown <david.brown@hesbynett.no>,
Anthony Youngman <antlists@youngman.org.uk>,
Phil Turmel <philip@turmel.org>, "Ravi (Tom) Hale" <ravi@hale.ee>,
Linux-RAID <linux-raid@vger.kernel.org>
Subject: Re: A sector-of-mismatch warning patch (was Re: Fault tolerance with badblocks)
Date: Fri, 19 May 2017 14:49:51 +1000 [thread overview]
Message-ID: <87h90hlac0.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <871sroscey.fsf@esperi.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1209 bytes --]
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.
But I'm OK with this patch as it stands.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2017-05-19 4:49 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-04 10:04 Fault tolerance in RAID0 with badblocks Ravi (Tom) Hale
2017-05-04 13:44 ` Wols Lists
2017-05-05 4:03 ` Fault tolerance " Ravi (Tom) Hale
2017-05-05 19:20 ` Anthony Youngman
2017-05-06 11:21 ` Ravi (Tom) Hale
2017-05-06 13:00 ` Wols Lists
2017-05-08 14:50 ` Nix
2017-05-08 18:00 ` Anthony Youngman
2017-05-09 10:11 ` David Brown
2017-05-09 10:18 ` Nix
2017-05-08 19:02 ` Phil Turmel
2017-05-08 19:52 ` Nix
2017-05-08 20:27 ` Anthony Youngman
2017-05-09 9:53 ` Nix
2017-05-09 11:09 ` David Brown
2017-05-09 11:27 ` Nix
2017-05-09 11:58 ` David Brown
2017-05-09 17:25 ` Chris Murphy
2017-05-09 19:44 ` Wols Lists
2017-05-10 3:53 ` Chris Murphy
2017-05-10 4:49 ` Wols Lists
2017-05-10 17:18 ` Chris Murphy
2017-05-16 3:20 ` NeilBrown
2017-05-10 5:00 ` Dave Stevens
2017-05-10 16:44 ` Edward Kuns
2017-05-10 18:09 ` Chris Murphy
2017-05-09 20:18 ` Nix
2017-05-09 20:52 ` Wols Lists
2017-05-10 8:41 ` David Brown
2017-05-09 21:06 ` A sector-of-mismatch warning patch (was Re: Fault tolerance with badblocks) Nix
2017-05-12 11:14 ` Nix
2017-05-16 3:27 ` NeilBrown
2017-05-16 9:13 ` Nix
2017-05-16 21:11 ` NeilBrown
2017-05-16 21:46 ` Nix
2017-05-18 0:07 ` Shaohua Li
2017-05-19 4:53 ` NeilBrown
2017-05-19 10:31 ` Nix
2017-05-19 16:48 ` Shaohua Li
2017-06-02 12:28 ` Nix
2017-05-19 4:49 ` NeilBrown [this message]
2017-05-19 10:32 ` Nix
2017-05-19 16:55 ` Shaohua Li
2017-05-21 22:00 ` NeilBrown
2017-05-09 19:16 ` Fault tolerance with badblocks Phil Turmel
2017-05-09 20:01 ` Nix
2017-05-09 20:57 ` Wols Lists
2017-05-09 21:22 ` Nix
2017-05-09 21:23 ` Phil Turmel
2017-05-09 21:32 ` NeilBrown
2017-05-10 19:03 ` Nix
2017-05-09 16:05 ` Chris Murphy
2017-05-09 17:49 ` Wols Lists
2017-05-10 3:06 ` Chris Murphy
2017-05-08 20:56 ` Phil Turmel
2017-05-09 10:28 ` Nix
2017-05-09 10:50 ` Reindl Harald
2017-05-09 11:15 ` Nix
2017-05-09 11:48 ` Reindl Harald
2017-05-09 16:11 ` Nix
2017-05-09 16:46 ` Reindl Harald
2017-05-09 7:37 ` David Brown
2017-05-09 9:58 ` Nix
2017-05-09 10:28 ` Brad Campbell
2017-05-09 10:40 ` Nix
2017-05-09 12:15 ` Tim Small
2017-05-09 15:30 ` Nix
2017-05-05 20:23 ` Peter Grandi
2017-05-05 22:14 ` Nix
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h90hlac0.fsf@notabene.neil.brown.name \
--to=neilb@suse.com \
--cc=antlists@youngman.org.uk \
--cc=david.brown@hesbynett.no \
--cc=linux-raid@vger.kernel.org \
--cc=lists@colorremedies.com \
--cc=nix@esperi.org.uk \
--cc=philip@turmel.org \
--cc=ravi@hale.ee \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).