Re: question about bitmaps and dirty percentile

5 messages, 3 authors, 2009-08-07 · open the first message on its own page

Re: question about bitmaps and dirty percentile

From: Neil Brown <hidden>
Date: 2009-08-06 06:21:45

On Thursday July 30, jnelson-linux-raid@jamponi.net wrote:
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
Certainly very strange.  I cannot explain it at all.

Please report exactly what kernel version you were running, all kernel
log messages from before the first resync completed until after the
sync-to-200% completed.

Hopefully there will be a clue somewhere in there.

Thanks,
NeilBrown

Re: question about bitmaps and dirty percentile

From: Jon Nelson <hidden>
Date: 2009-08-06 13:02:39

On Thu, Aug 6, 2009 at 1:21 AM, Neil Brown[off-list ref] wrote:
On Thursday July 30, jnelson-linux-raid@jamponi.net wrote:
quoted
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
Certainly very strange.  I cannot explain it at all.

Please report exactly what kernel version you were running, all kernel
log messages from before the first resync completed until after the
sync-to-200% completed.

Hopefully there will be a clue somewhere in there.
Stock openSUSE 2.6.27.25-0.1-default on x86_64.

I'm pretty sure this is it:

Jul 30 13:51:01 turnip kernel: md: bind<nbd0>
Jul 30 13:51:01 turnip kernel: RAID1 conf printout:
Jul 30 13:51:01 turnip kernel:  --- wd:1 rd:3
Jul 30 13:51:01 turnip kernel:  disk 0, wo:0, o:1, dev:sde
Jul 30 13:51:01 turnip kernel:  disk 1, wo:1, o:1, dev:nbd0
Jul 30 13:51:01 turnip kernel: md: recovery of RAID array md12
Jul 30 13:51:01 turnip kernel: md: minimum _guaranteed_  speed: 1000
KB/sec/disk.
Jul 30 13:51:01 turnip kernel: md: using maximum available idle IO
bandwidth (but not more than 200000 KB/sec) for recovery.
Jul 30 13:51:01 turnip kernel: md: using 128k window, over a total of
72612988 blocks.
Jul 30 14:10:48 turnip kernel: md: md12: recovery done.
Jul 30 14:10:49 turnip kernel: RAID1 conf printout:
Jul 30 14:10:49 turnip kernel:  --- wd:2 rd:3
Jul 30 14:10:49 turnip kernel:  disk 0, wo:0, o:1, dev:sde
Jul 30 14:10:49 turnip kernel:  disk 1, wo:0, o:1, dev:nbd0


-- 
Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: question about bitmaps and dirty percentile

From: NeilBrown <hidden>
Date: 2009-08-07 01:47:20

On Thu, August 6, 2009 11:02 pm, Jon Nelson wrote:
On Thu, Aug 6, 2009 at 1:21 AM, Neil Brown[off-list ref] wrote:
quoted
On Thursday July 30, jnelson-linux-raid@jamponi.net wrote:
quoted
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
Certainly very strange.  I cannot explain it at all.

Please report exactly what kernel version you were running, all kernel
log messages from before the first resync completed until after the
sync-to-200% completed.

Hopefully there will be a clue somewhere in there.
Stock openSUSE 2.6.27.25-0.1-default on x86_64.
Ok, so it was probably broken by whoever maintain md for
SuSE.... oh wait, that's me :-)

I'm pretty sure this is it:

Jul 30 13:51:01 turnip kernel: md: bind<nbd0>
Jul 30 13:51:01 turnip kernel: RAID1 conf printout:
Jul 30 13:51:01 turnip kernel:  --- wd:1 rd:3
Jul 30 13:51:01 turnip kernel:  disk 0, wo:0, o:1, dev:sde
Jul 30 13:51:01 turnip kernel:  disk 1, wo:1, o:1, dev:nbd0
Jul 30 13:51:01 turnip kernel: md: recovery of RAID array md12
Jul 30 13:51:01 turnip kernel: md: minimum _guaranteed_  speed: 1000
KB/sec/disk.
Jul 30 13:51:01 turnip kernel: md: using maximum available idle IO
bandwidth (but not more than 200000 KB/sec) for recovery.
Jul 30 13:51:01 turnip kernel: md: using 128k window, over a total of
72612988 blocks.
Jul 30 14:10:48 turnip kernel: md: md12: recovery done.
Jul 30 14:10:49 turnip kernel: RAID1 conf printout:
Jul 30 14:10:49 turnip kernel:  --- wd:2 rd:3
Jul 30 14:10:49 turnip kernel:  disk 0, wo:0, o:1, dev:sde
Jul 30 14:10:49 turnip kernel:  disk 1, wo:0, o:1, dev:nbd0
Thanks...
So:
 - when the recovery started, mddev->size was twice of half of the value
   printed for "over a total of...", so 72612988 (I assume this is
   expected to be a 72 Gig array).
   Twice this will have been stored in 'max_sectors' and the loop in
   md_do_sync will have taken 'j' up to that value and periodically
   stored in in mddev->curr_resync
 - When you ran "cat /proc/mdstat", mddev->array_sectors will have been
   twice the value printed at "... blocks", which is the same,
   145225976
 - When you ran "cat /proc/mdstat", it printed "recovery", not "resync",
   so MD_RECOVERY_SYNC was not set, so max_sectors was set to
   mddev->size... that looks wrong (size is in KB)
   Half of this is printed in the second number in
   the (%d/%d) bit, so ->size was twice 36306494 or
   72612988, which is consistent.

So the problem is that in resync_status, max_sectors is being set to
mddev->size rather than mddev->size*2.  This is purely a cosmetic problem,
it do not affect data safety at all.

It looks like I botched a backport of
  commit dd71cf6b2773310b01c6fe6c773064c80fd2476b
into the Suse kernel.  I'll get that fixed for the next update.

Thanks for the report, and as I said, the only thing affected here
is the content of /proc/mdstat.  The recovery is doing the right
thing.

Thanks,
NeilBrown


Re: question about bitmaps and dirty percentile

From: Jon Nelson <hidden>
Date: 2009-08-07 02:17:10

On Thu, Aug 6, 2009 at 8:47 PM, NeilBrown[off-list ref] wrote:
...
So the problem is that in resync_status, max_sectors is being set to
mddev->size rather than mddev->size*2.  This is purely a cosmetic problem,
it do not affect data safety at all.

It looks like I botched a backport of
 commit dd71cf6b2773310b01c6fe6c773064c80fd2476b
into the Suse kernel.  I'll get that fixed for the next update.

Thanks for the report, and as I said, the only thing affected here
is the content of /proc/mdstat.  The recovery is doing the right
thing.
Sweet! Open Source is AWESOME.


-- 
Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: question about bitmaps and dirty percentile

From: John Robinson <hidden>
Date: 2009-08-07 12:29:55

On 07/08/2009 03:17, Jon Nelson wrote:
Sweet! Open Source is AWESOME.
Amen to that, brother Jon!
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help