From: Bill Davidsen <davidsen@tmr.com>
To: Christian Pernegger <pernegger@gmail.com>
Cc: David Rees <drees76@gmail.com>, Linux RAID <linux-raid@vger.kernel.org>
Subject: Re: raid10 vs raid5 - strange performance
Date: Wed, 26 Mar 2008 12:29:05 -0400 [thread overview]
Message-ID: <47EA79D1.1090607@tmr.com> (raw)
In-Reply-To: <bb145bd20803251556pa416a0cs8350058a4216f6f9@mail.gmail.com>
Christian Pernegger wrote:
>> Not surprising at all. Read performance is similar between the two
>> setups as expected (appears to be limited by the PCI bus).
>>
>
> Yes, reads are fine.
>
>
>> Streaming write performance is better because you are writing less
>> redundant data to disks, you can now stripe writes over 5 disks
>> instead of 3.
>>
>
> Sounds reasonable. Write performance SHOULD be ~5x single disk for
> raid5 and ~3x single disk for raid10 in a theoretical best-case
> scenario, either should hit the PCI bus cap. In reality the ratios are
> more like 1x for raid5 and 0.6 -1.1x for raid10. It's just that I'd
> expected ~ identical and significantly better streaming write
> performance from both array configurations ... then again, if you
> think it over,
>
> raid5 will transfer 1 parity block per 5 data blocks (so 5/6 of the
> PCI bw are usable = 92MB)
> raid10 will transfer 3 copy blocks per 3 data blocks (so 1/2 of the
> PCI bw are usable = 55MB)
>
> Factoring in some contention / overhead my values might well be
> normal. It just means that the fabled raid10 only performs if you have
> high-bw buses, which this box sadly doesn't, or a hw controller where
> redundant blocks don't go over the bus, which the 3ware 7506
> apparently isn't.
>
> I'll still go with raid10 for the 50% better random I/O, only less
> enthusiastically.
>
I think that you should treat 10,n2 and 10,f2 as separate
configurations, and test them as such. behavior is quite different, and
one or the other might be a better fit to your usage.
The ability to transfer a single copy of the data and no parity
information is an advantage of hardware controllers.
--
Bill Davidsen <davidsen@tmr.com>
"Woe unto the statesman who makes war without a reason that will still
be valid when the war is over..." Otto von Bismark
next prev parent reply other threads:[~2008-03-26 16:29 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-25 21:33 raid10 vs raid5 - strange performance Christian Pernegger
2008-03-25 22:13 ` David Rees
2008-03-25 22:56 ` Christian Pernegger
2008-03-26 16:29 ` Bill Davidsen [this message]
2008-03-26 17:10 ` Christian Pernegger
2008-03-26 17:49 ` Keld Jørn Simonsen
2008-03-25 23:36 ` Keld Jørn Simonsen
[not found] ` <bb145bd20803251837x7ef1fa9dk6191fcaea7b02144@mail.gmail.com>
[not found] ` <20080326072416.GA8674@rap.rap.dk>
2008-03-26 17:16 ` Christian Pernegger
2008-03-26 19:29 ` Keld Jørn Simonsen
2008-03-27 1:11 ` Christian Pernegger
2008-03-27 9:18 ` Keld Jørn Simonsen
[not found] ` <47EAACAB.7070203@tmr.com>
2008-03-27 2:02 ` Christian Pernegger
2008-03-29 20:25 ` Bill Davidsen
2008-03-29 21:26 ` Iustin Pop
2008-03-30 8:55 ` Keld Jørn Simonsen
2008-03-30 9:34 ` Keld Jørn Simonsen
2008-03-30 11:16 ` Peter Grandi
2008-03-30 12:58 ` Keld Jørn Simonsen
2008-03-30 14:21 ` Keld Jørn Simonsen
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=47EA79D1.1090607@tmr.com \
--to=davidsen@tmr.com \
--cc=drees76@gmail.com \
--cc=linux-raid@vger.kernel.org \
--cc=pernegger@gmail.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 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.