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 08:52:06 -0400 [thread overview]
Message-ID: <1121259126.5504.14.camel@localhost.localdomain> (raw)
In-Reply-To: <87eka2g9dp.fsf@uwo.ca>
On Wed, 2005-07-13 at 08:48 -0400, Dan Christensen wrote:
> Ming Zhang <mingz@ele.uri.edu> writes:
>
> > have u try the parallel write?
>
> I haven't tested it as thoroughly, as it brings lvm and the filesystem
> into the mix. (The disks are in "production" use, and are fairly
> full, so I can't do writes directly to the disk partitions/raid
> device.)
test on a production environment is too dangerous. :P
and many benchmark tool u can not perform as well.
LVM overhead is small, but file system overhead is hard to say.
>
> 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.
but if you write on file system and file system has meta data write, log
write, then things become complicated. you can use iostat to see r/w on
your disk.
> Dan
next prev parent reply other threads:[~2005-07-13 12:52 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 [this message]
2005-07-13 14:23 ` Dan Christensen
2005-07-13 14:29 ` Ming Zhang
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=1121259126.5504.14.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 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).