linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Doug Ledford <dledford@redhat.com>
To: Piergiorgio Sartor <piergiorgio.sartor@nexgo.de>
Cc: linux-raid@vger.kernel.org
Subject: Re: mdadm 3.1.x and bitmap chunk
Date: Mon, 02 Aug 2010 14:41:14 -0400	[thread overview]
Message-ID: <4C57114A.4000100@redhat.com> (raw)
In-Reply-To: <20100609210541.GA12153@lazy.lzy>

[-- Attachment #1: Type: text/plain, Size: 1799 bytes --]

On 06/09/2010 05:05 PM, Piergiorgio Sartor wrote:
> Hi folks,
> 
> I just noticed that mdadm 3.1.x sets the default
> bitmap chunk to 64MB.
> 
> Searching around, I found the reason should be
> related with write performances, which seem to
> be less compromised with large bitmap chunks.
> 
> I've no problem with that, but is it possible
> to set the bitmap chunk to the minimum size,
> without trying all the possible dimensions?
> 
> Thanks a lot in advance,
> 
> bye,
> 

This depends somewhat on what you mean by "minimum size" to the bitmap
chunk.  The bitmap chunk size can never be smaller than the minimum size
on the device, so 512bytes for most drives, 4k for newer drives.  But
such a chunk size would be horrible for performance as it would make
every single write synchronous on the bitmap update.  However, the
minimum size can also be limited by the available space for the bitmap
when using an internal bitmap.  So, you can only make the size as small
as it will go and the bitmap still fit between the end of the
{array,superblock} and the start of the {superblock,array}.

However, in general, a bitmap that's small enough that you can sync the
dirty section in a second or two should be good enough.  With modern
disks, they can sync 32MB or 64MB in only a second or two, hence the
default size.  Anything less than that is really a case of diminishing
returns.  You are sacrificing write speed on each and every write to the
array in exchange for a *possible* speed up in the event of a crash.
Not a very good trade off IMO.

-- 
Doug Ledford <dledford@redhat.com>
              GPG KeyID: CFBFF194
	      http://people.redhat.com/dledford

Infiniband specific RPMs available at
	      http://people.redhat.com/dledford/Infiniband


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

  reply	other threads:[~2010-08-02 18:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-09 21:05 mdadm 3.1.x and bitmap chunk Piergiorgio Sartor
2010-08-02 18:41 ` Doug Ledford [this message]
2010-08-03 18:36   ` Piergiorgio Sartor
2010-08-04  1:03     ` Doug Ledford
2010-08-04 19:53       ` Piergiorgio Sartor

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=4C57114A.4000100@redhat.com \
    --to=dledford@redhat.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=piergiorgio.sartor@nexgo.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).