All of lore.kernel.org
 help / color / mirror / Atom feed
* bitmap questions
@ 2010-10-13 16:24 Arkadiusz Miskiewicz
  2010-10-14  5:02 ` Paul Clements
  0 siblings, 1 reply; 5+ messages in thread
From: Arkadiusz Miskiewicz @ 2010-10-13 16:24 UTC (permalink / raw)
  To: linux-raid

Hi,

I have a question on how bitmap works and what's shown in /proc/mdstat, for 
example:

md2 : active raid10 sdc3[0] sdd3[3] sdb3[2] sda3[1]
      60002560 blocks 64K chunks 2 near-copies [4/4] [UUUU]
      bitmap: 1/1 pages [4KB], 65536KB chunk

- 1 bitmap for 4096 chunks

- if it shows 0/1 pages [0KB] what does it actually mean? Does that mean that 
in case of resync it will resync _all_ 4096 chunks in that page or only chunks 
that require that (for example 7 chunks) ?

- if it will resync all 4096 chunks what's the point of even allowing 1 page 
setup (via mdadm)?

Thanks!
-- 
Arkadiusz Miśkiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/

-- 
Arkadiusz Miśkiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/
--
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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: bitmap questions
  2010-10-13 16:24 bitmap questions Arkadiusz Miskiewicz
@ 2010-10-14  5:02 ` Paul Clements
  2010-10-14  6:00   ` Arkadiusz Miskiewicz
  0 siblings, 1 reply; 5+ messages in thread
From: Paul Clements @ 2010-10-14  5:02 UTC (permalink / raw)
  To: Arkadiusz Miskiewicz; +Cc: linux-raid

On Wed, Oct 13, 2010 at 12:24 PM, Arkadiusz Miskiewicz
<a.miskiewicz@gmail.com> wrote:

> I have a question on how bitmap works and what's shown in /proc/mdstat, for
> example:
>
> md2 : active raid10 sdc3[0] sdd3[3] sdb3[2] sda3[1]
>      60002560 blocks 64K chunks 2 near-copies [4/4] [UUUU]
>      bitmap: 1/1 pages [4KB], 65536KB chunk
>
> - 1 bitmap for 4096 chunks
>
> - if it shows 0/1 pages [0KB] what does it actually mean?

If it's 0 pages then no resync.
I assume you mean 1/1 ?

> Does that mean that
> in case of resync it will resync _all_ 4096  chunks in that page or only chunks
> that require that (for example 7 chunks) ?

It only resyncs what is dirty. A page dirty in the in-memory bitmap
does not mean ALL bits are dirty, just that the page is allocated.

--
Paul
--
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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: bitmap questions
  2010-10-14  5:02 ` Paul Clements
@ 2010-10-14  6:00   ` Arkadiusz Miskiewicz
  2010-10-14 12:11     ` John Robinson
  2010-10-14 12:39     ` Mario 'BitKoenig' Holbe
  0 siblings, 2 replies; 5+ messages in thread
From: Arkadiusz Miskiewicz @ 2010-10-14  6:00 UTC (permalink / raw)
  To: Paul Clements; +Cc: linux-raid

On Thursday 14 of October 2010, Paul Clements wrote:
> On Wed, Oct 13, 2010 at 12:24 PM, Arkadiusz Miskiewicz
> 
> <a.miskiewicz@gmail.com> wrote:
> > I have a question on how bitmap works and what's shown in /proc/mdstat,
> > for example:
> > 
> > md2 : active raid10 sdc3[0] sdd3[3] sdb3[2] sda3[1]
> >      60002560 blocks 64K chunks 2 near-copies [4/4] [UUUU]
> >      bitmap: 1/1 pages [4KB], 65536KB chunk
> > 
> > - 1 bitmap for 4096 chunks
> > 
> > - if it shows 0/1 pages [0KB] what does it actually mean?
> 
> If it's 0 pages then no resync.
> I assume you mean 1/1 ?

Ok, I thought differently since it's bitmap->pages - bitmap->missing_pages 
(thought that missing_pages == dirty one).

> > Does that mean that
> > in case of resync it will resync _all_ 4096  chunks in that page or only
> > chunks that require that (for example 7 chunks) ?
> 
> It only resyncs what is dirty. A page dirty in the in-memory bitmap
> does not mean ALL bits are dirty, just that the page is allocated.

So there is no way to know in advance how much is going to be resynced when 
sudden reset would happen in that moment?

Anyway good to know that 1 page setup also makes sense :)

> --
> Paul

-- 
Arkadiusz Miśkiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/
--
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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: bitmap questions
  2010-10-14  6:00   ` Arkadiusz Miskiewicz
@ 2010-10-14 12:11     ` John Robinson
  2010-10-14 12:39     ` Mario 'BitKoenig' Holbe
  1 sibling, 0 replies; 5+ messages in thread
From: John Robinson @ 2010-10-14 12:11 UTC (permalink / raw)
  To: Arkadiusz Miskiewicz; +Cc: linux-raid

On 14/10/2010 07:00, Arkadiusz Miskiewicz wrote:
[...]
> So there is no way to know in advance how much is going to be resynced when
> sudden reset would happen in that moment?

Only in the general sense that there's a limit to how many chunks could 
have been dirtied in whatever period your kernel will hang on to stuff 
before insisting on flushing it. I think that defaults to 5 seconds, so 
you'd have to have a pathological workload to dirty so many chunks the 
resync might take more than a minute.

Cheers,

John.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: bitmap questions
  2010-10-14  6:00   ` Arkadiusz Miskiewicz
  2010-10-14 12:11     ` John Robinson
@ 2010-10-14 12:39     ` Mario 'BitKoenig' Holbe
  1 sibling, 0 replies; 5+ messages in thread
From: Mario 'BitKoenig' Holbe @ 2010-10-14 12:39 UTC (permalink / raw)
  To: linux-raid

Arkadiusz Miskiewicz <a.miskiewicz@gmail.com> wrote:
> So there is no way to know in advance how much is going to be resynced when 
> sudden reset would happen in that moment?

mdadm -X /dev/component-device


regards
   Mario
-- 
To err is human. To really foul things up requires a computer.


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2010-10-14 12:39 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-10-13 16:24 bitmap questions Arkadiusz Miskiewicz
2010-10-14  5:02 ` Paul Clements
2010-10-14  6:00   ` Arkadiusz Miskiewicz
2010-10-14 12:11     ` John Robinson
2010-10-14 12:39     ` Mario 'BitKoenig' Holbe

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.