From: "Keld Jørn Simonsen" <keld@keldix.com>
To: Leslie Rhorer <lrhorer@satx.rr.com>
Cc: "'Keld Jørn Simonsen'" <keld@keldix.com>,
'NeilBrown' <neilb@suse.de>,
linux-raid@vger.kernel.org
Subject: Re: mdadm raid1 read performance
Date: Fri, 6 May 2011 23:53:39 +0200 [thread overview]
Message-ID: <20110506215339.GA24391@www2.open-std.org> (raw)
In-Reply-To: <89.70.16951.22664CD4@cdptpa-omtalb.mail.rr.com>
On Fri, May 06, 2011 at 04:20:39PM -0500, Leslie Rhorer wrote:
> > -----Original Message-----
> > From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-
> > owner@vger.kernel.org] On Behalf Of Keld Jørn Simonsen
> > Sent: Thursday, May 05, 2011 6:10 AM
> > To: NeilBrown
> > Cc: Liam Kurmos; Roberto Spadim; Brad Campbell; Drew; linux-
> > raid@vger.kernel.org
> > Subject: Re: mdadm raid1 read performance
> >
> > On Thu, May 05, 2011 at 09:45:38AM +1000, NeilBrown wrote:
> > > On Thu, 5 May 2011 00:08:59 +0100 Liam Kurmos <quantum.leaf@gmail.com>
> > wrote:
> > >
> > > > 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.
> >
> > Actually, theoretically, it should be more than that for reading, more
> > like N minus
> > some overhead. In a raid5 stripe of 4 disks, when reading you do not read
> > the checksum block, and thus you should be able to have all 4 drives
> > occupied with reading real data. Some benchmarks back this up,
> > http://home.comcast.net/~jpiszcz/20080329-raid/
> > http://blog.jamponi.net/2008/07/raid56-and-10-benchmarks-on-26255_10.html
> > The latter reports a 3.44 times performance for raid5 reads with 4
> > disks, significantly over the N-1 = 3.0 mark.
> >
> > For writing, you are correct with the N-1 formular.
>
> There have been a lot of threads here about array performance, but
> one important factor rarely mentioned in these threads is network
> performance. Of course, network performance is really outside the scope of
> this list, but I frequently see people talking about performance well in
> excess of 120MBps. That's great, but I have to wonder if their network
> actually can make use of such speeds. Of course, if the application
> actually obtaining the raw data is on the machine, then network performance
> is much less of an issue. A database search implemented directly on the
> server, for example, can use every bit of performance available to the local
> machine. Given that in my case the vast majority of data is squirted across
> the LAN (e.g., these are mostly file servers), anything much in excess of
> 120MBps is irrelevant. I mean, yeah, its a rather nice feeling that my
> RAID arrays can deliver more than 450MBps if they are ever called upon to do
> so, but with a 1G LAN, that's not going to happen very often. I just wonder
> how many people who complain of poor performance can really benefit all that
> much from increased performance?
10 Gbit/s connections are getting commonplace these days, at least in the
environments that I operate in.
Best regards
keld
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2011-05-06 21:53 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
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 [this message]
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=20110506215339.GA24391@www2.open-std.org \
--to=keld@keldix.com \
--cc=linux-raid@vger.kernel.org \
--cc=lrhorer@satx.rr.com \
--cc=neilb@suse.de \
/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.