linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Keld Jørn Simonsen" <keld@dkuug.dk>
To: linux-raid@vger.kernel.org
Subject: raid10 far layout outperforms offset at writing? (was: Help with chunksize on raid10 -p o3 array)
Date: Wed, 17 Dec 2008 13:41:54 +0100	[thread overview]
Message-ID: <20081217124154.GA5406@rap.rap.dk> (raw)

I found this old message:

> Peter Rabbitson
> Mon, 19 Mar 2007 06:14:38 -0800
> 
> Peter Rabbitson wrote:
> 
>     I have been trying to figure out the best chunk size for raid10
> before migrating my server to it (currently raid1). I am looking at 3
> offset stripes, as I want to have two drive failure redundancy, and
> offset striping is said to have the best write performance, with read
> performance equal to far. 
> 
> Incorporating suggestions from previous posts (thank you everyone), I
> used this modified script at http://rabbit.us/pool/misc/raid_test2.txt
> To negate effects of caching memory was jammed below 200mb free by using
> a full tmpfs mount with no swap. Here is what I got with far layout (-p
> f3): http://rabbit.us/pool/misc/raid_far.html The clear winner is 1M
> chunks, and is very consistent at any block size. I was surprised even
> more to see that my read speed was identical to that of a raid0 getting
> near the _maximum_ physical speed of 4 drives (roughly 55MB sustained
> across 1.2G). Unlike offset layout, far really shines at reading stuff
> back. The write speed did not suffer noticeably compared to offset
> striping. Here are the results (-p o3) for comparison:
> http://rabbit.us/pool/misc/raid_offset.html, and they roughly seem to
> correlate with my earlier testing using dd.
> 
> So I guess the way to go for this system will be f3, although the md(4)
> says that offset layout should be more beneficial. Is there anything I
> missed while setting my o3 array, so that I got worse performance for
> both read and write compared to f3?
> 
> Once again thanks everyone for the help.
> Peter

The links were not valid anymore. I wanted to see the results and 
possibly include the results in the performance wiki page
I would appreciate some new links here.

Furthermore some comments to the post: My take on o3 vs f3 is that both
in theory and practice f3 should be much faster for sequential reading,
as the layout is equivalent to raid0. For random reading and sequential
and random writing f3 and o3 (and the same goes for the more normal f2
vs o2) should be about the same, especially when a filesystem and
its associated elevator algorithm is employed.

Best regards
keld

             reply	other threads:[~2008-12-17 12:41 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-17 12:41 Keld Jørn Simonsen [this message]
2008-12-17 12:50 ` raid10 far layout outperforms offset at writing? (was: Help with chunksize on raid10 -p o3 array) Peter Rabbitson
2008-12-17 14:34   ` Keld Jørn Simonsen
  -- strict thread matches above, loose matches on Subject: below --
2007-03-06 11:26 Help with chunksize on raid10 -p o3 array Peter Rabbitson
2007-03-19 14:14 ` raid10 far layout outperforms offset at writing? (was: Help with chunksize on raid10 -p o3 array) Peter Rabbitson

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=20081217124154.GA5406@rap.rap.dk \
    --to=keld@dkuug.dk \
    --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).