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: Mon, 23 Jul 2007 17:21:35 +1000	[thread overview]
Message-ID: <18084.22271.122052.80056@notabene.brown> (raw)
In-Reply-To: message from Mike Snitzer on Saturday July 21

On Saturday July 21, snitzer@gmail.com wrote:
> On 6/1/06, NeilBrown <neilb@suse.de> wrote:
> >
> > When an array has a bitmap, a device can be removed and re-added
> > and only blocks changes since the removal (as recorded in the bitmap)
> > will be resynced.
> 
> Neil,
> 
> Does the same apply when a bitmap-enabled raid1's member goes faulty?
> Meaning even if a member is faulty, when the user removes and re-adds
> the faulty device the raid1 rebuild _should_ leverage the bitmap
> during a resync right?

Yes and no.

While the array is degraded, bits are never cleared from the bitmap.
So if you remove and re-add a device from a degraded array, then all
the block that have changed since the array became degraded will need
to be recovered.  This will likely be more than where changed while
the device was temporarily removed from the array, but probably much
less than the entire array.

> 
> I've seen messages like:
> [12068875.690255] raid1: raid set md0 active with 2 out of 2 mirrors
> [12068875.690284] md0: bitmap file is out of date (0 < 1) -- forcing
> full recovery
> [12068875.690289] md0: bitmap file is out of date, doing full recovery
> [12068875.710214] md0: bitmap initialized from disk: read 5/5 pages,
> set 131056 bits, status: 0
> [12068875.710222] created bitmap (64 pages) for device md0
> 
> Could you share the other situations where a bitmap-enabled raid1
> _must_ perform a full recovery?

When you add a new drive.  When you create a new bitmap.  I think that
should be all.

> - Correct me if I'm wrong, but one that comes to mind is when a server
> reboots (after cleanly stopping a raid1 array that had a faulty
> member) and then either:
> 1) assembles the array with the previously faulty member now
> available
> 
> 2) assembles the array with the same faulty member missing.  The user
> later re-adds the faulty member
> 
> AFAIK both scenarios would bring about a full resync.

Only if the drive is not recognised as the original member.
Can you test this out and report a sequence of events that causes a
full resync?

NeilBrown

  reply	other threads:[~2007-07-23  7:21 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 [this message]
2007-07-23 12:47   ` Mike Snitzer
2007-08-03  6:42     ` Neil Brown
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=18084.22271.122052.80056@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).