linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "NeilBrown" <neilb@suse.de>
To: John Robinson <john.robinson@anonymous.org.uk>
Cc: Linux RAID <linux-raid@vger.kernel.org>
Subject: Re: Poor write performance with write-intent bitmap?
Date: Tue, 21 Apr 2009 11:33:21 +1000 (EST)	[thread overview]
Message-ID: <4081b80da35818efbc07723240f8ea36.squirrel@neil.brown.name> (raw)
In-Reply-To: <49ED16F7.3040906@anonymous.org.uk>

On Tue, April 21, 2009 10:44 am, John Robinson wrote:
> That's more like it, and no more rattling. Can I tune settings for the
> internal bitmap, or is this something which will have improved anyway
> since my kernel (2.6.18-128.1.6.el5.centos.plusxen so essentially a
> prominent North American Enterprise Linux vendor's EL5 codebase for
> md/raid5)? I mean, I do want the bitmap, but I hadn't realised it was
> quite so expensive (not that it matters much in this particular
> application).
>

I don't think newer kernels make any different to bitmap related
performance, though there might be some general raid5 improvements since
then.

There are two tunables for bitmaps.  Chuck size and delay (though the
delay doesn't seem to be in the man page).

Choosing a larger --bitmap-chunk size will require fewer updates to the
bitmap before writes are allowed to proceed.   However a larger bitmap-chunk
size will also increase the amount of work needed after a crash or
re-added device.
Check your current (default) chunk size with "mdadm -X /dev/sdxx" and
create a new bitmap with (say) 16 or 64 times the chunk size.
See if that makes a difference.

The delay tunable sets how quickly bits are removed from the bitmap.
This is done fairly lazily and opportunistically so it isn't likely
to affect throughput directly.  However if you are updates the same
area on disk periodically, and this period is a little bit more than
the timeout, you will get excessive bitmap updates that service little
purpose.
You could try increasing this (to say 30 or 60 seconds), but I doubt
it will have much effect.

Your other option is to put the bitmap in a file on some other device.
If you have a device this is rarely used (maybe your root filesystem)
you can create an external bitmap on there.  You would want to be
sure that the device storing the bitmap is always going to be
available when you start the array that the bitmap belongs to.

Maybe you could create an external bitmap in a tmpfs.... but then
it wouldn't survive a crash and so has little value.  It would be
fast though :-)

NeilBrown


> Cheers,
>
> John.
>
> --
> 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
>


  reply	other threads:[~2009-04-21  1:33 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-20 17:12 Performance of a software raid 5 Johannes Segitz
2009-04-20 23:46 ` John Robinson
2009-04-21  0:10   ` Johannes Segitz
2009-04-21  0:52     ` John Robinson
2009-04-21  1:05       ` Johannes Segitz
2009-04-21  1:12         ` John Robinson
2009-04-21  1:19         ` NeilBrown
2009-04-21  2:04           ` Johannes Segitz
2009-04-21  5:46             ` Neil Brown
2009-04-21 12:40               ` Johannes Segitz
2009-04-24 13:49                 ` Johannes Segitz
2009-04-26 17:03               ` Johannes Segitz
2009-04-21 18:56             ` Corey Hickey
2009-04-22 12:29               ` Bill Davidsen
2009-04-22 22:32                 ` Corey Hickey
2009-04-22  9:07           ` Goswin von Brederlow
2009-04-21  0:44   ` Poor write performance with write-intent bitmap? John Robinson
2009-04-21  1:33     ` NeilBrown [this message]
2009-04-21  2:13       ` John Robinson
2009-04-21  5:50         ` Neil Brown
2009-04-21 12:05           ` John Robinson
2009-05-22 23:00             ` Redeeman
2009-04-22  9:16         ` Goswin von Brederlow
2009-04-22 12:41           ` John Robinson
2009-04-22 14:02             ` Goswin von Brederlow
2009-04-23  7:48               ` John Robinson
2009-04-22 14:21             ` Andre Noll
2009-04-23  8:04               ` John Robinson
2009-04-23 20:23                 ` Goswin von Brederlow
2009-04-21 16:00       ` Bill Davidsen

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=4081b80da35818efbc07723240f8ea36.squirrel@neil.brown.name \
    --to=neilb@suse.de \
    --cc=john.robinson@anonymous.org.uk \
    --cc=linux-raid@vger.kernel.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 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).