linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: Liam Kurmos <quantum.leaf@gmail.com>
Cc: Roberto Spadim <roberto@spadim.com.br>,
	Brad Campbell <lists2009@fnarfbargle.com>,
	Drew <drew.kay@gmail.com>,
	linux-raid@vger.kernel.org
Subject: Re: mdadm raid1 read performance
Date: Thu, 5 May 2011 09:45:38 +1000	[thread overview]
Message-ID: <20110505094538.0cef02cc@notabene.brown> (raw)
In-Reply-To: <BANLkTikQTKPuY+Mg8h9ZOkJPoEQ-jGTeLg@mail.gmail.com>

On Thu, 5 May 2011 00:08:59 +0100 Liam Kurmos <quantum.leaf@gmail.com> wrote:

> Thanks to all who replied on this.
> 
> I somewhat naively assumed that having 2 disks with the same data
> would mean a similar read speed to raid0 should be the norm (and i
> think this is a very popular miss-conception).
> I was neglecting the seek time to skip alternate blocks which i guess
> must the flaw.
> 
> In theory though if i was reading a larger file, couldn't one disk
> start reading at the beginning to a buffer and one start reading from
> half way ( assuming 2 disks) and hence get close to 2x single d

isk
> speed?

If you write your program to read from both the beginning and the middle
then you might get double-speed.  The kernel doesn't know you are going to do
this so the best it can do is read-ahead is large amounts.

raid1 could notice large reads and send some to one disk and some to another,
but the size for each device must be large enough that the time to seek over
must be much less than the time to read, which is probably many megabytes on
todays hardware - and raid1 has no way to know what that size is.

Certainly it is possible that the read_balance code in md/raid1 could be
improved.  As yet no-one has improved it and provided convincing performance
numbers.

> 
> as a separate question, what should be the theoretical performance of raid5?

x(N-1)

So a 4 drive RAID5 should read at 3 time the speed of a single drive.

> 
> in my tests i read 1GB and throw away the data.
> dd if=/dev/md0 of=/dev/null bs=1M count=1000
> 
> With 4 fairly fast hdd's i get

Which apparently do 140MB/s:

> 
> raid0: ~540MB/s

I would expect 4*140 == 560, so this is a good result.

> raid10: 220MB/s

Assuming the default 'n2' layout, I would expect 2*140 or 280, so this is a
little slow.  Try "--layout=f2" and see what you get (should be more like
RAID0).

> raid5: ~165MB/s

I would expect 3*140 or 420, so this is very slow.  I wonder if read-ahead is
set badly.
Can you:
   blockdev --getra /dev/md0
multiply the number it gives you by 8 and give it back with
   blockdev --setra NUMBER /dev/md0


> raid1: ~140MB/s  (single disk speed)

as expected.

> 
> for 4 disks raid0 seems like suicide, but for my system drive the
> speed advantage is so great im tempted to try it anyway and try and
> use rsync to keep constant back up.

If you have somewhere to rsync to, then you have more disks so RAID10 might
be an answer... but I suspect you cannot move disks around that freely :-)

NeilBrown



> 
> cheers for you responses,
> 
> Liam

  parent reply	other threads:[~2011-05-04 23:45 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-04  0:07 mdadm raid1 read performance Liam Kurmos
2011-05-04  0:57 ` John Robinson
2011-05-06 20:44   ` Leslie Rhorer
2011-05-06 21:56     ` Keld Jørn Simonsen
2011-05-04  0:58 ` NeilBrown
2011-05-04  5:30   ` Drew
2011-05-04  6:31     ` Brad Campbell
2011-05-04  7:42       ` Roberto Spadim
2011-05-04 23:08         ` Liam Kurmos
2011-05-04 23:35           ` Roberto Spadim
2011-05-04 23:36           ` Brad Campbell
2011-05-04 23:45           ` NeilBrown [this message]
2011-05-04 23:57             ` Roberto Spadim
2011-05-05  0:14             ` Liam Kurmos
2011-05-05  0:20               ` Liam Kurmos
2011-05-05  0:25                 ` Roberto Spadim
2011-05-05  0:40                   ` Liam Kurmos
2011-05-05  7:26                     ` David Brown
2011-05-05 10:41                       ` Keld Jørn Simonsen
2011-05-05 11:38                         ` David Brown
2011-05-06  4:14                           ` CoolCold
2011-05-06  7:29                             ` David Brown
2011-05-06 21:05                       ` Leslie Rhorer
2011-05-07 10:37                         ` David Brown
2011-05-07 10:58                           ` Keld Jørn Simonsen
2011-05-05  0:24               ` Roberto Spadim
2011-05-05 11:10             ` Keld Jørn Simonsen
2011-05-06 21:20               ` Leslie Rhorer
2011-05-06 21:53                 ` Keld Jørn Simonsen
2011-05-07  3:17                   ` Leslie Rhorer
2011-05-05  4:06           ` Roman Mamedov
2011-05-05  8:06             ` Nikolay Kichukov
2011-05-05  8:39               ` Liam Kurmos
2011-05-05  8:49                 ` Liam Kurmos
2011-05-05  9:30               ` NeilBrown
2011-05-04  7:48       ` David Brown

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=20110505094538.0cef02cc@notabene.brown \
    --to=neilb@suse.de \
    --cc=drew.kay@gmail.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=lists2009@fnarfbargle.com \
    --cc=quantum.leaf@gmail.com \
    --cc=roberto@spadim.com.br \
    /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).