All of lore.kernel.org
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: Marc MERLIN <marc@merlins.org>
Cc: linux-raid@vger.kernel.org
Subject: Re: Intent Bitmap size and performance
Date: Sun, 2 Feb 2014 17:28:32 +1100	[thread overview]
Message-ID: <20140202172832.30e33c05@notabene.brown> (raw)
In-Reply-To: <20140202005646.GC25441@merlins.org>

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

On Sat, 1 Feb 2014 16:56:46 -0800 Marc MERLIN <marc@merlins.org> wrote:

> On Sat, Feb 01, 2014 at 04:39:15PM -0800, Marc MERLIN wrote:
> > How can I tell I got the size for my array size?
> 
> Aah, the clue seems to be in the kernel logs:
> [669348.274368] md7: bitmap file is out of date (0 < 38029) -- forcing full recovery
> [669348.299174] created bitmap (15 pages) for device md7
> [669348.316720] md7: bitmap file is out of date, doing full recovery
> [669348.380555] md7: bitmap initialized from disk: read 1 pages, set 29809 of 29809 bits
> 
> If I got the math right, 30K bits for 8TB is one bit per 266MB.
> 
> Given that, I'm going to assume that this is not going to impact system
> performance much for most operations.
> 
> Is my assumption and conclusion correct?
> 
> Thanks,
> Marc

You can also use "mdadm --examine-bitmap" on one of the component devices to
get more details about the bitmap.

My rule-of-thumb (base on zero hard evidence) is that one bit should
correspond to approximately 1 second of IO.  Your bits correspond to 2 or 3
seconds so that is certainly the right ball park.

As always with RAID, performance is highly dependent on load.
It is quite easy to add and remove bitmaps to/from a live md array so
testing the effect on a particular workload is not that hard.

The default mdadm chooses is a bit complex.  It first chooses an amount of
space to reserve for the bitmap, the it figures what chunk size will allow
the bits to fit in the available space.  Then makes sure that it as least
64Meg.

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

  reply	other threads:[~2014-02-02  6:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-02  0:39 Intent Bitmap size and performance Marc MERLIN
2014-02-02  0:56 ` Marc MERLIN
2014-02-02  6:28   ` NeilBrown [this message]
2014-02-06 19:05     ` Marc MERLIN
2014-02-06 21:21       ` NeilBrown

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=20140202172832.30e33c05@notabene.brown \
    --to=neilb@suse.de \
    --cc=linux-raid@vger.kernel.org \
    --cc=marc@merlins.org \
    /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.