mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Neil Brown <neilb@suse.de>
To: Mike Snitzer <snitzer@gmail.com>
Cc: linux-raid@vger.kernel.org, linux-kernel@vger.kernel.org,
	paul.clements@steeleye.com
Subject: Re: [RFC][PATCH] md: avoid fullsync if a faulty member missed a dirty transition
Date: Tue, 6 May 2008 16:53:58 +1000	[thread overview]
Message-ID: <18464.134.236488.251879@notabene.brown> (raw)
In-Reply-To: message from Mike Snitzer on Wednesday April 2

On Wednesday April 2, snitzer@gmail.com wrote:
> resync via bitmap if faulty's events+1 == bitmap's events_cleared
> 
> For more background please see:
> http://marc.info/?l=linux-raid&m=120703208715865&w=2
> 
> Without this change validate_super() will prevent the previously faulty
> member from recovering via bitmap, e.g.:

I can't help thinking that you are misinterpreting something.  I don't
think there is a clean->dirty transition happening here.
You could confirm this by using --examine on both devices after the
messy shutdown and before re-assembling the array.

Even allowing for that possible confusion, I cannot quite see what is
going on.
It is fairly clear from the event counts that the NBD device is marked
clean, but if this is happening at array-shutdown time, I cannot see
why md would try to write to the NBD device and thereby detect an
error...

Do you have an internal bitmap or a bitmap in an external file?

In general, I would not like to make decisions based on the
oddness/evenness of the event counter.  I consider that to be an
internal implementation detail.  I am happy to make decisions based on
a difference-of-1.  I need to understand the big picture first though.

NeilBrown

  reply	other threads:[~2008-05-06  6:54 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-02 22:09 Mike Snitzer
2008-05-06  6:53 ` Neil Brown [this message]
2008-05-06 11:58   ` Mike Snitzer
2008-05-08  6:13     ` Neil Brown
2008-05-08 20:11       ` Mike Snitzer
2008-05-09  1:40         ` Neil Brown
2008-05-09  4:42           ` Mike Snitzer
2008-05-09  5:08             ` Mike Snitzer
2008-05-09  5:26               ` Mike Snitzer
2008-05-09  6:01             ` Neil Brown
2008-05-09 15:00               ` Mike Snitzer
2008-05-16 11:54                 ` Neil Brown
2008-05-19  4:33                   ` Mike Snitzer
2008-05-19  5:27                     ` Neil Brown
2008-05-20 15:30                       ` Mike Snitzer
2008-05-20 15:33                         ` Mike Snitzer
2008-05-27  6:56                         ` Neil Brown
2008-05-27 14:33                           ` Mike Snitzer

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=18464.134.236488.251879@notabene.brown \
    --to=neilb@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=paul.clements@steeleye.com \
    --cc=snitzer@gmail.com \
    /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

all inboxes | Powered by JetHome®