* 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.