linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Brown <david@westcontrol.com>
To: linux-raid@vger.kernel.org
Subject: Re: Mirrored volume peformance questions
Date: Wed, 04 May 2011 09:42:40 +0200	[thread overview]
Message-ID: <ipqvv6$ru1$1@dough.gmane.org> (raw)
In-Reply-To: <20110503213430.GC24265@www2.open-std.org>

On 03/05/2011 23:34, Keld Jørn Simonsen wrote:
> On Tue, May 03, 2011 at 04:52:07PM -0300, Roberto Spadim wrote:
>> 2011/5/3 Morad, Steve<morad@amazon.com>:
>>> I have a few questions about volume mirroring performance
>>> implications.
>>>
>>
>>> 2. Similarly, would a RAID10 configuration give me the same (or
>>> better) read behavior across these same disks, while providing
>>> twice the storage capacity of the above configuration?
>
> RAID10 and RAID1 gives the same storage capacity with the same
> disks.
>

Perhaps he meant a 4-drive RAID1 set?  That way reads for any data can 
be taken for any drive.

> Linux MD RAID10 is actually just another way of doing raid1-like
> layouts.
>
>
>> in md world raid1+ raid0 != raid10
>>
>> raid10 can use layouts raid1 can?t
>>
>> raid10 have diferent read_balance algorithms than raid1 raid10 with
>> far layout is better optimized for sequencial read (it?s like raid0
>> stripe) raid10 with near/offset layoute are better optimized for
>> multthread
>
> Hmm, raid10 near, offset and far are about the same for multithread,
> according to several benchmarks. Actually the far layout has
> significant better random read performance than the near layout in
> some thests, about 25 % better speed, and about 100 % bettter speed
> than raid1.
>

raid10,far is better for sequential reads - it gives better-than-raid0 
performance on average since it will do striped reads from the faster 
outer tracks.  And for multi-threaded reads, it should also be a little 
faster than other raid10 layouts (and raid1, which is much the same as 
raid10,near).  Since it prefers to get the data from the outer half, you 
get the benefits of short-stroking your disks - faster transfer speeds 
and less head movement.

The cost of raid10,far is greater head movement for writes - but that is 
not the OP's main concern.

If I interpreted correctly that the OP is considering a 4-way mirror, 
then perhaps raid10,f4 is ideal - sequential reads will be taken from 
all drives at once (in the outer quarter of the disks), and for 
multi-thread reads all requested data can be found on any of the disks.

--
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

  parent reply	other threads:[~2011-05-04  7:42 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-03 19:42 Mirrored volume peformance questions Morad, Steve
2011-05-03 19:52 ` Roberto Spadim
2011-05-03 21:34   ` Keld Jørn Simonsen
2011-05-03 21:40     ` Roberto Spadim
2011-05-04  7:42     ` David Brown [this message]
2011-05-04  8:13       ` Keld Jørn Simonsen
2011-05-04 15:43         ` Roberto Spadim

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='ipqvv6$ru1$1@dough.gmane.org' \
    --to=david@westcontrol.com \
    --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).