All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Rees <drees76@gmail.com>
To: Ryan Wagoner <rswagoner@gmail.com>
Cc: Bill Davidsen <davidsen@tmr.com>,
	Alain Williams <addw@phcomp.co.uk>,
	linux-raid@vger.kernel.org
Subject: Re: High IO Wait with RAID 1
Date: Fri, 13 Mar 2009 11:37:02 -0700	[thread overview]
Message-ID: <72dbd3150903131137m1106e302oa6b36d1270bb10f@mail.gmail.com> (raw)
In-Reply-To: <7d86ddb90903131042i2bd6aba9o9bae3a99fdcdae5f@mail.gmail.com>

On Fri, Mar 13, 2009 at 10:42 AM, Ryan Wagoner <rswagoner@gmail.com> wrote:
> Yeah I understand the basics to RAID and the effect cache has on
> performance. It just seems that RAID 1 should offer better write
> performance than a 3 drive RAID 5 array. However I haven't run the
> numbers so I could be wrong.

If we just look at best case scenario write throughput where N is the
number of disks in the array:

RAID1 = 1
RAID5 = N-1

So for your case, your RAID5 array should be able to write up to twice
as fast as your RAID1 array.  This could be enough to explain the
difference in load.

Where RAID5 writes slow down significantly is if you are writing
chunks smaller than the stripe size and the affected stripe isn't in
cache and a read has to be performed before the write to recalculate
the parity.

But for your use case of transferring large VM images, this is
unlikely to be the case.

In otherwords, what you are experiencing (high IO wait writing to the
RAID1 arrays) is to be expected.  From the stats you posted earlier,
it looks like you are maxing out the write speed of the RAID1 arrays -
thus you end up with high IO wait times.

> It could be just that I expect too much from RAID 1. I'm debating
> about reloading the box with RAID 10 across 160GB of the 4 drives
> (160GB and 320GB) and a mirror on the remaining space. In theory this
> should gain me write performance.

Yes, a RAID10 with 4 disks will get you up to twice the write
performance and up to 4 times the read performance without the
drawback of small writes losing performance due to parity reads.

-Dave

  reply	other threads:[~2009-03-13 18:37 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-12 23:46 High IO Wait with RAID 1 Ryan Wagoner
2009-03-13  0:48 ` Alain Williams
2009-03-13  3:21   ` Ryan Wagoner
2009-03-13  9:39     ` Robin Hill
2009-03-13 10:17     ` Alain Williams
     [not found]       ` <7d86ddb90903130519p4268dc33vc8ad42b53aefa2e2@mail.gmail.com>
2009-03-13 12:21         ` Fwd: " Ryan Wagoner
2009-03-13 16:22     ` Bill Davidsen
2009-03-13 17:42       ` Ryan Wagoner
2009-03-13 18:37         ` David Rees [this message]
2009-03-13 18:42   ` David Rees
2009-03-13 14:48 ` John Robinson
2009-03-13 18:02 David Lethe
2009-03-13 18:29 ` Ryan Wagoner
2009-03-13 22:10   ` David Rees

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=72dbd3150903131137m1106e302oa6b36d1270bb10f@mail.gmail.com \
    --to=drees76@gmail.com \
    --cc=addw@phcomp.co.uk \
    --cc=davidsen@tmr.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=rswagoner@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.