From: Ming Zhang <mingz@ele.uri.edu>
To: Dan Christensen <jdc@uwo.ca>
Cc: Linux RAID <linux-raid@vger.kernel.org>
Subject: Re: RAID-5 streaming read performance
Date: Wed, 13 Jul 2005 10:29:57 -0400 [thread overview]
Message-ID: <1121264997.5504.29.camel@localhost.localdomain> (raw)
In-Reply-To: <87vf3eeqe2.fsf@uwo.ca>
On Wed, 2005-07-13 at 10:23 -0400, Dan Christensen wrote:
> Ming Zhang <mingz@ele.uri.edu> writes:
>
> > test on a production environment is too dangerous. :P
> > and many benchmark tool u can not perform as well.
>
> Well, I put "production" in quotes because this is just a home mythtv
> box. :-) So there are plenty of times when it is idle and I can do
> benchmarks. But I can't erase the hard drives in my tests.
>
> > LVM overhead is small, but file system overhead is hard to say.
>
> I expected LVM overhead to be small, but in my tests it is very high.
> I plan to discuss this on the lvm mailing list after I've got the RAID
> working as well as possible, but as an example:
>
> Streaming reads using dd to /dev/null:
>
> component partitions, e.g. /dev/sda7: 58MB/s
> raid device /dev/md2: 59MB/s
> lvm device /dev/main/media: 34MB/s
>
> So something is seriously wrong with my lvm set-up (or with lvm). The
> lvm device is linearly mapped to the initial blocks of md2, so the
> last two tests should be reading the same blocks from disk.
this is interesting.
>
> >> My preliminary finding is that raid writes are faster than non-raid
> >> writes: 49MB/s vs 39MB/s. Still not stellar performance, though.
> >> Question for the list: if I'm doing a long sequential write, naively
> >> each parity block will get recalculated and rewritten several times,
> >> once for each non-parity block in the stripe. Does the write-caching
> >> that the kernel does mean that each parity block will only get written
> >> once?
> >
> > if you write sequential, you might see a stripe write thus write only
> > once.
>
> Glad to hear it. In that case, sequential writes to a RAID-5 device
> with 4 physical drives should be up to 3 times faster than writes to a
> single device (ignoring journaling, time for calculating parity, bus
> bandwidth issues, etc).
sounds reasonable but hard to see i feel.
>
> Is this "stripe write" something that the md layer does to optimize
> things? In other words, does the md layer cache writes and write a
> stripe at a time when that's possible? Or is this just an automatic
> effect of the general purpose write-caching that the kernel does?
md people will give you more details. :)
>
> > but if you write on file system and file system has meta data write, log
> > write, then things become complicated.
>
> Yes. For now I'm starting at the bottom and working up...
>
> > you can use iostat to see r/w on your disk.
>
> Thanks, I'll try that.
>
> Dan
next prev parent reply other threads:[~2005-07-13 14:29 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-11 15:11 RAID-5 streaming read performance Dan Christensen
2005-07-13 2:08 ` Ming Zhang
2005-07-13 2:52 ` Dan Christensen
2005-07-13 3:15 ` berk walker
2005-07-13 12:24 ` Ming Zhang
2005-07-13 12:48 ` Dan Christensen
2005-07-13 12:52 ` Ming Zhang
2005-07-13 14:23 ` Dan Christensen
2005-07-13 14:29 ` Ming Zhang [this message]
2005-07-13 17:56 ` Dan Christensen
2005-07-13 22:38 ` Neil Brown
2005-07-14 0:09 ` Ming Zhang
2005-07-14 1:16 ` Neil Brown
2005-07-14 1:25 ` Ming Zhang
2005-07-13 18:02 ` David Greaves
2005-07-13 18:14 ` Ming Zhang
2005-07-13 21:18 ` David Greaves
2005-07-13 21:44 ` Ming Zhang
2005-07-13 21:50 ` David Greaves
2005-07-13 21:55 ` Ming Zhang
2005-07-13 22:52 ` Neil Brown
2005-07-14 3:58 ` Dan Christensen
2005-07-14 4:13 ` Mark Hahn
2005-07-14 21:16 ` Dan Christensen
2005-07-14 21:30 ` Ming Zhang
2005-07-14 23:29 ` Mark Hahn
2005-07-15 1:23 ` Ming Zhang
2005-07-15 2:11 ` Dan Christensen
2005-07-15 12:28 ` Ming Zhang
2005-07-14 12:30 ` Ming Zhang
2005-07-14 14:23 ` Ming Zhang
2005-07-14 17:54 ` Dan Christensen
2005-07-14 18:00 ` Ming Zhang
2005-07-14 18:03 ` Dan Christensen
2005-07-14 18:10 ` Ming Zhang
2005-07-14 19:16 ` Dan Christensen
2005-07-14 20:13 ` Ming Zhang
2005-07-15 2:38 ` Dan Christensen
2005-07-15 6:01 ` Holger Kiehl
2005-07-15 12:29 ` Ming Zhang
2005-07-13 22:42 ` Neil 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=1121264997.5504.29.camel@localhost.localdomain \
--to=mingz@ele.uri.edu \
--cc=jdc@uwo.ca \
--cc=linux-raid@vger.kernel.org \
/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.