All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: Peter Rabbitson <rabbit+list@rabbit.us>
Cc: "H. Peter Anvin" <hpa@zytor.com>, linux-raid@vger.kernel.org
Subject: Re: Raid6 write performance
Date: Fri, 13 Mar 2009 13:11:47 -0400	[thread overview]
Message-ID: <49BA93D3.9070700@tmr.com> (raw)
In-Reply-To: <49AADFCA.2060406@rabbit.us>

Peter Rabbitson wrote:
> H. Peter Anvin wrote:
>   
>> Peter Rabbitson wrote:
>>     
>>> Hi,
>>>
>>> I am experimenting with raid6 on 4 drives on 2.6.27.11. The problem I am
>>> having is that no matter what chunk size I use, the write benchmark
>>> always comes out at single drive speed, although I should be seeing
>>> double drive speed (read speed is at near 4x as expected).
>>>       
>> I have no idea why you "should" be seeing double drive speed.  All
>> drives have to be written, so you'd logically see single drive speed.
>>
>>     
>
> Because with properly adjusted elevators and chunk sizes it is reasonable
> to expect N * S write speed from _any_ raid, where N is the number of
> different data bearing disks in a stripe, and S is the speed of a hard
> drive (assuming the drive speeds are equal). So for raid5 we have N =
> numdisks-1, for raid6 numdisks-2, for raid10 -n4 -pf3 we get 4-(3-1) and
> so on. I have personally verified the write behavior for raid10 and raid5,
> don't see why it should/would be different for raid6.
>   

That's a lovely theory, but in practice I have to say I have never 
measured any such thing, using benchmarks intended to match real world, 
or even heavy disk writes of a dumb nature like dd. I have tested 
through the raw device, and through filesystems, tuned stripe-cache-size 
and buffers, tried setting "stride" in ext3, all to conclude that with 
raid5 I see essentially write speed of 1x a single drive and read speed 
of (N-1)x as you suggest. Actually, looking at results for arrays with 
more drives I can see a trend to write at (N/3)x speed, being a 
seek-write for full chunk data and seef-read-write for XOR. But even on 
six drive arrays I don't get near (N-1)x in measurable.

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



      reply	other threads:[~2009-03-13 17:11 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-19  7:40 Raid6 write performance Peter Rabbitson
2009-01-19  8:10 ` thomas62186218
2009-01-19  9:07   ` NiftyFedora Mitch
2009-01-26 18:47     ` Bill Davidsen
2009-01-19 12:48   ` Keld Jørn Simonsen
2009-01-19 12:50     ` Peter Rabbitson
2009-01-19 10:37 ` Peter Rabbitson
2009-01-19 10:58   ` Bernd Schubert
2009-01-19 11:01     ` Peter Rabbitson
2009-01-19 11:08       ` Bernd Schubert
2009-02-28  1:04 ` H. Peter Anvin
2009-03-01 19:12   ` Michał Przyłuski
2009-03-01 20:35     ` H. Peter Anvin
2009-03-01 19:19   ` Peter Rabbitson
2009-03-13 17:11     ` 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=49BA93D3.9070700@tmr.com \
    --to=davidsen@tmr.com \
    --cc=hpa@zytor.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=rabbit+list@rabbit.us \
    /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.