From: Doug Ledford <dledford@redhat.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Neil F Brown <nfbrown@novell.com>, linux-raid@vger.kernel.org
Subject: Re: [ANNOUNCE] mdadm-3.1 has been withdrawn
Date: Fri, 13 Nov 2009 22:32:24 -0500 [thread overview]
Message-ID: <4AFE24C8.10002@redhat.com> (raw)
In-Reply-To: <e9c3a7c20911131554w28075d39mbc8bebc17a4ef260@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1454 bytes --]
On 11/13/2009 06:54 PM, Dan Williams wrote:
> On Mon, Nov 9, 2009 at 1:22 PM, Neil F Brown <nfbrown@novell.com> wrote:
>> I'm certainly happy with increasing the chunksize to 512K.
>
> Probably good for reads, but it makes it harder for the code to
> collect full stripe writes. I guess I should get some data to back
> that up one of these days...
My data (which I have, not that I need to get :-P) suggests that it
really doesn't matter. For streaming writes, the buffer cache stores
stuff up long enough to get a stripe write even when the stripe is huge.
For random writes, you don't normally get a full stripe no matter how
long you wait or how small the stripe is. I say this after looking at
the various performance parameters of a timed 5 minute dbench run and
also the random write time and rate of both 4k and 16k tiotest runs to
raid arrays from 4 to 7 disks and with chunk sizes from 256k up to 1024k
using ext2, ext3, ext4, and xfs filesystems. From those test results,
512k was roughly the sweet spot, streaming writes were effected far more
than random writes by chunk size, and both were probably even more
dependent on things other than chunk size (filesystem type and layout
for instance).
--
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: 197 bytes --]
next prev parent reply other threads:[~2009-11-14 3:32 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-06 6:45 [ANNOUNCE] mdadm-3.1 has been withdrawn Neil Brown
2009-11-09 14:39 ` Doug Ledford
2009-11-09 15:36 ` berk walker
2009-11-09 15:42 ` Jon Nelson
2009-11-09 16:51 ` Mikael Abrahamsson
2009-11-09 21:07 ` Doug Ledford
2009-11-09 21:27 ` Luca Berra
2009-11-09 21:43 ` Jon Nelson
2009-11-10 8:25 ` Mikael Abrahamsson
2009-11-10 14:22 ` Jon Nelson
2009-11-11 3:26 ` Michael Evans
2009-11-12 22:25 ` Bill Davidsen
2009-11-13 5:50 ` Mikael Abrahamsson
2009-11-13 13:04 ` Bill Davidsen
2009-11-09 20:22 ` Neil F Brown
2009-11-09 21:00 ` Doug Ledford
2009-11-13 23:54 ` Dan Williams
2009-11-14 3:32 ` Doug Ledford [this message]
[not found] <nfbrown@novell.com>
2009-11-12 17:51 ` greg
2009-11-12 23:02 ` Rudy Zijlstra
2009-11-13 1:53 ` Michael Evans
2009-11-13 2:02 ` Neil Brown
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=4AFE24C8.10002@redhat.com \
--to=dledford@redhat.com \
--cc=dan.j.williams@intel.com \
--cc=linux-raid@vger.kernel.org \
--cc=nfbrown@novell.com \
/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).