linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Clements <paul.clements@steeleye.com>
To: Mike Snitzer <snitzer@gmail.com>
Cc: linux-raid@vger.kernel.org, neilb@suse.de
Subject: Re: [PATCH] md: new bitmap sysfs interface
Date: Wed, 26 Jul 2006 22:27:23 -0400	[thread overview]
Message-ID: <44C8248B.7010501@steeleye.com> (raw)
In-Reply-To: <170fa0d20607261430n3e9d3962xeef50669ce0d1996@mail.gmail.com>

Mike Snitzer wrote:

> I tracked down the thread you referenced and these posts (by you)
> seems to summarize things well:
> http://marc.theaimsgroup.com/?l=linux-raid&m=111116563016418&w=2
> http://marc.theaimsgroup.com/?l=linux-raid&m=111117515400864&w=2
> 
> But for clarity's sake, could you elaborate on the negative
> implications of not merging the bitmaps on the secondary server?  Will
> the previous primary's dirty blocks get dropped on the floor because
> the secondary (now the primary) doesn't have awareness of the previous
> primary's dirty blocks once it activates the raid1?

Right. At the time of the failover, there were (probably) blocks that 
were out of sync between the primary and secondary. Now, after you've 
failed over to the secondary, you've got to overwrite those blocks with 
data from the secondary in order to make the primary disk consistent 
again. This requires that either you do a full resync from secondary to 
primary (if you don't know what differs), or you merge the two bitmaps 
and resync just that data.

> Also, what is the interface one should use to collect dirty bits from
> the primary's bitmap?

Whatever you'd like. scp the bitmap file over or collect the ranges into 
a file and scp that over, or something similar.

> This bitmap merge can't happen until the primary's dirty bits can be
> collected right?  Waiting for the failed server to come back to

Right. So, when the primary fails, you start the array on the secondary 
with a _clean_ bitmap, and just its local disk component. Now, whatever 
gets written while the primary is down gets put into the bitmap on the 
secondary. When the primary comes back up, you take the dirty bits from 
it and add them into the secondary's bitmap. Then, you insert the 
primary's disk (via nbd or similar) back into the array, and begin a 
resync.

That's the whole reason for this interface. We have to modify the bitmap 
while the array is active (modifying the bitmap while the array is down 
is trivial, and certainly doesn't require sysfs :).

> harvest the dirty bits it has seems wrong (why failover at all?); so I
> must be missing something.

We fail over immediately. We wait until later to combine the bitmaps and 
resync the data.

Hope that helps.

--
Paul

  reply	other threads:[~2006-07-27  2:27 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-25  6:30 [PATCH] md: new bitmap sysfs interface Paul Clements
2006-07-25 17:41 ` dave rientjes
2006-07-26 21:30 ` Mike Snitzer
2006-07-27  2:27   ` Paul Clements [this message]
2006-07-27  3:36     ` Mike Snitzer
2006-07-27 14:07       ` Paul Clements
2006-07-27 14:28     ` Mike Snitzer
2006-07-27 14:55       ` Paul Clements
2006-08-03  1:42 ` Neil Brown
2006-08-03  1:53   ` Paul Clements
2006-08-03  7:24   ` David Greaves
2006-08-03 15:39     ` Mr. James W. Laferriere

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=44C8248B.7010501@steeleye.com \
    --to=paul.clements@steeleye.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@suse.de \
    --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).