All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Clements <paul.clements@steeleye.com>
To: Jon Nelson <jnelson-linux-raid@jamponi.net>
Cc: LinuxRaid <linux-raid@vger.kernel.org>
Subject: Re: question about bitmaps and dirty percentile
Date: Fri, 31 Jul 2009 14:17:53 -0400	[thread overview]
Message-ID: <4A733551.5010408@steeleye.com> (raw)
In-Reply-To: <cccedfc60907301216h769eadd7oc575dd3ae04f64bb@mail.gmail.com>

Jon Nelson wrote:
> On Thu, Jul 30, 2009 at 1:25 PM, Jon
> Nelson<jnelson-linux-raid@jamponi.net> wrote:
>> Then things got weird.
>>
>> I saw this, which just *can't* be right:
>>
>> md12 : active raid1 nbd0[2](W) sde[0]
>>      72612988 blocks super 1.1 [3/1] [U__]
>>      [======================================>]  recovery =192.7%
>> (69979200/36306494) finish=13228593199978.6min speed=11620K/sec
>>      bitmap: 139/139 pages [556KB], 256KB chunk
>>
>> and of course the percentile kept growing, and the finish minutes are crazy.
> 
> Weirdness: it ready 199 (or so) and then completed:
> 
> md12 : active raid1 nbd0[2](W) sde[0]
>       72612988 blocks super 1.1 [3/2] [UU_]
>       bitmap: 139/139 pages [556KB], 256KB chunk
> 
> I --fail, --remove the device, and then --re-add it.
> 
> The recovery *starts over*, as if nothing had happened over the last hour or so.
> The event counter are very close between /dev/nbd0 (the device here)
> and /dev/sde (the core device), within a dozen or so, but the "dirty
> percentile" on /dev/nbd0 is big - 18.8%, and unchanging between runs.
> It's like the bitmap isn't getting updated, or getting updated
> incompletely, or something.
> 
> Does the bitmap only get updated when *all* devices have sync'd???
> I'll let you know in about 2 hours.

The bitmap never gets cleared unless all disks in the array are in sync.

--
Paul

  reply	other threads:[~2009-07-31 18:17 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-30 18:25 question about bitmaps and dirty percentile Jon Nelson
2009-07-30 19:16 ` Jon Nelson
2009-07-31 18:17   ` Paul Clements [this message]
2009-07-31 19:09     ` Jon Nelson
2009-08-03 16:44       ` Matthias Urlichs
2009-08-03 20:30         ` Paul Clements
2009-08-06  6:21 ` Neil Brown
2009-08-06 13:02   ` Jon Nelson
2009-08-07  1:47     ` NeilBrown
2009-08-07  2:17       ` Jon Nelson
2009-08-07 12:29         ` John Robinson

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=4A733551.5010408@steeleye.com \
    --to=paul.clements@steeleye.com \
    --cc=jnelson-linux-raid@jamponi.net \
    --cc=linux-raid@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.