linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Neil Brown <neilb@suse.de>
To: Mike Snitzer <snitzer@gmail.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: Need clarification on raid1 resync behavior with bitmap support
Date: Fri, 3 Aug 2007 16:42:48 +1000	[thread overview]
Message-ID: <18098.52840.936611.7816@notabene.brown> (raw)
In-Reply-To: message from Mike Snitzer on Monday July 23

On Monday July 23, snitzer@gmail.com wrote:
> On 7/23/07, Neil Brown <neilb@suse.de> wrote:
> > Can you test this out and report a sequence of events that causes a
> > full resync?
> 
> Sure, using an internal-bitmap-enabled raid1 with 2 loopback devices
> on a stock 2.6.20.1 kernel, the following sequences result in a full
> resync.  (FYI, I'm fairly certain I've seen this same behavior on
> 2.6.18 and 2.6.15 kernels too but would need to retest):
> 
> 1)
> mdadm /dev/md0 --manage --fail /dev/loop0
> mdadm -S /dev/md0
> mdadm --assemble /dev/md0 /dev/loop0 /dev/loop1
>   mdadm: /dev/md0 has been started with 1 drive (out of 2).
>   NOTE: kernel log says:  md: kicking non-fresh loop0 from array!
> mdadm /dev/md0 --manage --re-add /dev/loop0


sorry for the slow response.

It looks like commit 1757128438d41670ded8bc3bc735325cc07dc8f9
(December 2006) set conf->fullsync a litte too often.

This seems to fix it, and I'm fairly sure it is correct.

Thanks,
NeilBrown

----------------------------------
Make sure a re-add after a restart honours bitmap when resyncing.

Commit 1757128438d41670ded8bc3bc735325cc07dc8f9 was slightly bad.
If and array has a write-intent bitmap, and you remove a drive,
then readd it, only the changes parts should be resynced.
This only works if the array has not been shut down and restarted.

The above mentioned commit sets 'fullsync' at little more often
than it should.  This patch is more careful.

Signed-off-by: Neil Brown <neilb@suse.de>

### Diffstat output
 ./drivers/md/raid1.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff .prev/drivers/md/raid1.c ./drivers/md/raid1.c
--- .prev/drivers/md/raid1.c	2007-07-31 11:21:29.000000000 +1000
+++ ./drivers/md/raid1.c	2007-08-03 16:24:23.000000000 +1000
@@ -1918,7 +1918,8 @@ static int run(mddev_t *mddev)
 		    !test_bit(In_sync, &disk->rdev->flags)) {
 			disk->head_position = 0;
 			mddev->degraded++;
-			conf->fullsync = 1;
+			if (disk->rdev)
+				conf->fullsync = 1;
 		}
 	}
 	if (mddev->degraded == conf->raid_disks) {

  reply	other threads:[~2007-08-03  6:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-21 16:59 Need clarification on raid1 resync behavior with bitmap support Mike Snitzer
2007-07-23  7:21 ` Neil Brown
2007-07-23 12:47   ` Mike Snitzer
2007-08-03  6:42     ` Neil Brown [this message]
2007-08-03 13:41       ` Mike Snitzer
2007-08-03 21:33         ` Neil Brown
2007-08-06 15:30           ` Mike Snitzer
2007-08-10  5:15             ` Neil Brown
2008-01-27 19:44           ` 2 failed disks RAID 5 behavior bug? TJ Harrell

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=18098.52840.936611.7816@notabene.brown \
    --to=neilb@suse.de \
    --cc=linux-raid@vger.kernel.org \
    --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;
as well as URLs for NNTP newsgroup(s).