From: keld@keldix.com
To: Charles Polisher <cpolish@surewest.net>
Cc: Peter Rabbitson <rabbit+list@rabbit.us>,
Phil Turmel <philip@turmel.org>,
linux-raid@vger.kernel.org
Subject: Re: Suboptimal raid6 linear read speed
Date: Tue, 15 Jan 2013 20:57:07 +0100 [thread overview]
Message-ID: <20130115195707.GA30921@www5.open-std.org> (raw)
In-Reply-To: <20130115170937.GA8831@kevin>
On Tue, Jan 15, 2013 at 09:09:38AM -0800, Charles Polisher wrote:
> On Tue, Jan 15, 2013 at 11:55:07PM +1100, Peter Rabbitson wrote:
> > On Tue, Jan 15, 2013 at 07:49:10AM -0500, Phil Turmel wrote:
> > > You are neglecting each drive's need to skip over parity blocks. If the
> > > array's chunk size is small, the drives won't have to seek, just wait
> > > for the platter spin. Larger chunks might need a seek.
> >
> > > Either way, you
> > > won't get better than (single drive rate) * (n-2) where "n" is the
> > > number of drives in your array. (Large sequential reads.)
> >
> > This can't be right. As far as I know the md layer is smarter than that, and
> > includes various anticipatory codepaths specifically to leverage multiple
> > drives in this fashion. Fwiw raid5 does give me the near-expected speed
> > (n * single drive).
>
> Happen to be working with comparative benchmarks looking for
> relative throughput, varying the number of active drives in the
> array and the RAID level. Clearly in this data RAID6 sequential
> writes are bottlenecked by the 2 parity stripes. RAID6 setup
> increases from 2 non-parity drives in the 4 drive configuration
> to 6 non-parity drives in the 8 drive configuration, so one
> might hope for 3x advantage. Yet the data show an advantage of
> only 1.83 for reads. My guess is the need to read the parity
> stripes is again a limiting factor. Next benchmark will vary
> stripe and stride.
>
> Advantage Advantage
> vs 4 drives vs RAID0
> Config Drives Seq write Seq read Write Read Write Read
> ------ ------ ---------- ---------- ----- ----- ---- ----
> RAID0 4 8.1MB/sec 9.3MB/sec 1.00 1.00 1.00 1.00
> RAID0 8 16.8MB/sec 15.0MB/sec 2.07 1.61 1.00 1.00
>
> RAID1 4 2.1MB/sec 3.6MB/sec 1.00 1.00 0.25 0.38
> RAID1 8 1.6MB/sec 3.6MB/sec 0.76 1.00 0.09 0.24
>
> RAID5 4 16.8MB/sec 9.1MB/sec 1.00 1.00 2.07 0.97
> RAID5 8 17.2MB/sec 14.9MB/sec 1.02 1.63 2.12 1.60
>
> RAID6 4 12.6MB/sec 7.9MB/sec 1.00 1.00 1.55 0.84
> RAID6 8 14.4MB/sec 14.5MB/sec 1.63 1.83 1.77 1.55
>
> RAID10 4 4.0MB/sec 7.3MB/sec 1.00 1.00 0.49 0.78
> RAID10 8 6.3MB/sec 13.4MB/sec 1.57 1.83 0.37 0.89
>
> Yes, these drives are *really* slow (Connor CP 30548).
> The math doesn't change.
> --
> Charles
What layout are you using for RAID10?
Is it Linux MD RAID10?
Best regards
Keld
next prev parent reply other threads:[~2013-01-15 19:57 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-15 12:33 Suboptimal raid6 linear read speed Peter Rabbitson
2013-01-15 12:45 ` Mikael Abrahamsson
2013-01-15 12:56 ` Peter Rabbitson
2013-01-15 16:13 ` Mikael Abrahamsson
2013-01-15 12:49 ` Phil Turmel
2013-01-15 12:55 ` Peter Rabbitson
2013-01-15 17:09 ` Charles Polisher
2013-01-15 19:57 ` keld [this message]
2013-01-16 4:43 ` Charles Polisher
2013-01-16 6:37 ` Tommy Apel Hansen
2013-01-16 9:36 ` keld
2013-01-16 16:09 ` Charles Polisher
2013-01-16 20:40 ` EJ Vincent
2013-01-15 23:17 ` Phil Turmel
2013-01-16 2:48 ` Stan Hoeppner
2013-01-16 2:58 ` Peter Rabbitson
2013-01-16 20:29 ` Stan Hoeppner
2013-01-16 21:20 ` Roy Sigurd Karlsbakk
2013-01-17 15:51 ` Mikael Abrahamsson
2013-01-18 8:31 ` Stan Hoeppner
2013-01-18 9:18 ` Mikael Abrahamsson
2013-01-18 22:56 ` Stan Hoeppner
2013-01-19 7:43 ` Mikael Abrahamsson
2013-01-19 22:48 ` Stan Hoeppner
2013-01-19 23:51 ` Maarten
2013-01-20 0:16 ` Chris Murphy
2013-01-20 0:49 ` Maarten
2013-01-20 1:37 ` Phil Turmel
2013-01-20 9:44 ` Chris Murphy
2013-01-20 6:26 ` Mikael Abrahamsson
2013-01-20 9:39 ` Chris Murphy
2013-01-20 16:55 ` Mikael Abrahamsson
2013-01-20 17:15 ` Chris Murphy
2013-01-20 17:17 ` Mikael Abrahamsson
2013-01-20 17:20 ` Chris Murphy
2013-01-19 23:53 ` Phil Turmel
2013-01-20 9:04 ` Wolfgang Denk
2013-01-20 19:28 ` Peter Grandi
2013-01-20 21:09 ` Mikael Abrahamsson
2013-01-20 21:50 ` Peter Grandi
2013-01-21 5:24 ` Mikael Abrahamsson
2013-01-21 14:40 ` Peter Rabbitson
2013-01-21 20:32 ` Peter Grandi
2013-01-21 20:55 ` Peter Grandi
2013-01-21 22:00 ` Peter Grandi
2013-01-19 13:21 ` Roy Sigurd Karlsbakk
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=20130115195707.GA30921@www5.open-std.org \
--to=keld@keldix.com \
--cc=cpolish@surewest.net \
--cc=linux-raid@vger.kernel.org \
--cc=philip@turmel.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 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).