From: Neil Brown <neilb@suse.de>
To: Roman Mamedov <roman@rm.pp.ru>
Cc: Bernd Schubert <bernd.schubert@fastmail.fm>, linux-raid@vger.kernel.org
Subject: Re: RAID6 and crashes (reporting back re. --bitmap)
Date: Mon, 14 Jun 2010 19:47:42 +1000 [thread overview]
Message-ID: <20100614194742.4a383a3f@notabene.brown> (raw)
In-Reply-To: <20100614151425.11f91562@natsu>
On Mon, 14 Jun 2010 15:14:25 +0600
Roman Mamedov <roman@rm.pp.ru> wrote:
> On Mon, 14 Jun 2010 09:05:20 +1000
> Neil Brown <neilb@suse.de> wrote:
>
> > > While I have done this myself a couple of times, I still do not understand
> > > where it takes the disk space for the bitmap journal from? Is this space
> > > mdadm reserved for this purpose?
> >
> > Sort-of.
> > It uses space that the alignment requirements of the metadata assure us is
> > otherwise unused.
> > For v0.90, that is limited to 60K. For 1.x it is 3K.
>
> I have now:
>
> md0 : active raid5 sdf3[3] sde3[1] sda3[0]
> 3887004672 blocks super 1.2 level 5, 64k chunk, algorithm 2 [3/3] [UUU]
> bitmap: 1/8 pages [4KB], 131072KB chunk
>
> Metadata is 1.2, and the internal bitmap is 8 pages, which is 32K, not 3K.
> Did I misunderstand something, or perhaps 3K was a typo?
>
The pages used to store the bitmap internally use 16 bits per bitmap-chunk,
to count how many active IO requests to the chunk there are. So it is
potentially 16 times the size of the bitmap stored on disk. For that reason
we free pages for which all chunks are idle. In your case, only one of the 8
pages currently has any active chunks.
There are 3887004672 / 131072 or about 29655 chunks. Hence bits.
29655/8 is 3706 bytes which you will notice is still larger than 3 K.
When you create an array an specify that a bitmap be added at the same time,
there is more flexibility for size and location of the bitmap. It can easily
be more that 3K in that case.
So presumably this array was created with a bitmap, rather than created
without a bitmap and had a bitmap added later with --grow. Correct?
NeilBrown
next prev parent reply other threads:[~2010-06-14 9:47 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-10 18:02 RAID6 and crashes Miles Fidelman
2010-06-10 18:57 ` Roman Mamedov
2010-06-10 21:22 ` RAID6 and crashes (reporting back re. --bitmap) Miles Fidelman
2010-06-10 21:41 ` Roman Mamedov
2010-06-10 22:40 ` Miles Fidelman
2010-06-11 2:51 ` Roman Mamedov
2010-06-11 4:31 ` Graham Mitchell
2010-06-11 4:41 ` Roman Mamedov
2010-06-11 12:13 ` Graham Mitchell
2010-06-11 4:42 ` Miles Fidelman
2010-06-11 4:50 ` Neil Brown
2010-06-13 14:28 ` Bernd Schubert
2010-06-13 23:05 ` Neil Brown
2010-06-14 9:01 ` Bernd Schubert
2010-06-14 9:14 ` Roman Mamedov
2010-06-14 9:47 ` Neil Brown [this message]
2010-06-14 11:53 ` Roman Mamedov
2010-06-14 21:24 ` Neil Brown
2010-06-11 4:46 ` Miles Fidelman
2010-06-11 4:55 ` Roman Mamedov
2010-06-11 20:26 ` Miles Fidelman
2010-06-11 5:08 ` Neil Brown
2010-06-11 11:10 ` John Hendrikx
2010-06-11 11:50 ` Roman Mamedov
2010-06-11 12:29 ` Graham Mitchell
2010-06-11 12:25 ` Graham Mitchell
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=20100614194742.4a383a3f@notabene.brown \
--to=neilb@suse.de \
--cc=bernd.schubert@fastmail.fm \
--cc=linux-raid@vger.kernel.org \
--cc=roman@rm.pp.ru \
/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.