From: Bill Davidsen <davidsen@tmr.com>
To: NeilBrown <neilb@suse.de>
Cc: John Robinson <john.robinson@anonymous.org.uk>,
Linux RAID <linux-raid@vger.kernel.org>
Subject: Re: Poor write performance with write-intent bitmap?
Date: Tue, 21 Apr 2009 12:00:23 -0400 [thread overview]
Message-ID: <49EDED97.5010706@tmr.com> (raw)
In-Reply-To: <4081b80da35818efbc07723240f8ea36.squirrel@neil.brown.name>
NeilBrown wrote:
> 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).
>
It isn't in the man page, and
mdadm --help | egrep 'bitmap|delay'
comes up empty as well. So then I looked at the strings:
strings $(type -p mdadm) | less
and I not only found it, but found that you have a vast bunch of
duplicate strings, including some which are saying the same thing but
expressed in several ways. If I might quote my offspring, "That's ugly,
dude!"
Anyway, setting "--delay N" (sec) does exactly what you predicted, not much.
--
bill davidsen <davidsen@tmr.com>
CTO TMR Associates, Inc
"You are disgraced professional losers. And by the way, give us our money back."
- Representative Earl Pomeroy, Democrat of North Dakota
on the A.I.G. executives who were paid bonuses after a federal bailout.
prev parent reply other threads:[~2009-04-21 16:00 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
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 [this message]
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=49EDED97.5010706@tmr.com \
--to=davidsen@tmr.com \
--cc=john.robinson@anonymous.org.uk \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@suse.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 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.