public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zaitsev <peter@mysql.com>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Mike Fedyk <mfedyk@matchmail.com>,
	Helge Hafting <helgehaf@aitel.hist.no>,
	jw schultz <jw@pegasys.ws>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: raid0 slower than devices it is assembled of?
Date: Wed, 17 Dec 2003 14:39:37 +0300	[thread overview]
Message-ID: <1071657159.2155.76.camel@abyss.local> (raw)
In-Reply-To: <Pine.LNX.4.58.0312161304390.1599@home.osdl.org>

On Wed, 2003-12-17 at 00:11, Linus Torvalds wrote:

> >
> > Larger stripes may help in general, but I'd suggest that for raid5 (ie, not
> > raid0), the stripe size should not be enlarged as much.  On many
> > filesystems, a bitmap change, or inode table update shouldn't require
> > reading a large stripe from several drives to complete the pairity
> > calculations.
> 
> Oh, absolutely. I only made the argument as it works for RAID0, ie just
> striping.  There the only downside of a large stripe is the potential for
> a lack of parallelism, but as mentioned, I don't think that downside much
> exists with modern disks - the platter density and throughput (once you've
> seeked to the right place) are so high that there is no point to try to
> parallelise it at the data transfer point.

I'm pretty curious about this argument,

Practically as RAID5 uses XOR for checksum computation you do not have
to read the whole stripe to recompute the checksum.

If you have lets say 1Mb stripe but modify  just  few bytes somewhere,
there is no reason why you can't read lets say 4KB blocks from 2
devices, and write updated 4K blocks back.

The problem here lies what some (many?) RAID controllers have cache-line
equals to stripe size,  so working with whole stripes only. Some (at
least Mylex) however have different settings for cache line size and
stripe size.

What is about it in Linux software RAID5 implementation  ?


One more issue with smaller stripes both for RAID5 and RAID0 (at least
for DBMS workloads) is - you normally want multi-block IO (ie fetching
many sequentially located pages) to be close in cost to reading single
page, which is true for single hard drive. However with small stripe
size you will hit many of underlying devices  putting excessive not
necessary load. 

I was also wondering is there any way in Linux to make sure files are
aligned to stripe size ?   Performing IO in some particular page size
you would not like these to come on stripe  border touching two devices
instead of one. 



-- 
Peter Zaitsev, Full-Time Developer
MySQL AB, www.mysql.com

Are you MySQL certified?  www.mysql.com/certification


  parent reply	other threads:[~2003-12-17 11:39 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-15 13:34 raid0 slower than devices it is assembled of? Witold Krecicki
2003-12-15 15:44 ` Witold Krecicki
2003-12-16  4:01 ` jw schultz
2003-12-16 14:51   ` Helge Hafting
2003-12-16 16:42     ` Linus Torvalds
2003-12-16 20:58       ` Mike Fedyk
2003-12-16 21:11         ` Linus Torvalds
2003-12-17 10:53           ` Jörn Engel
2003-12-17 11:39           ` Peter Zaitsev [this message]
2003-12-17 16:01             ` Linus Torvalds
2003-12-17 18:37               ` Mike Fedyk
2003-12-17 21:55               ` bill davidsen
2003-12-17 17:02             ` bill davidsen
2003-12-17 20:14               ` Peter Zaitsev
2003-12-17 19:22       ` Jamie Lokier
2003-12-17 19:40         ` Linus Torvalds
2003-12-17 22:36           ` bill davidsen
2003-12-18  2:47         ` jw schultz
2003-12-17 22:29       ` bill davidsen
2003-12-18  2:18         ` jw schultz
2004-01-08  4:54       ` Greg Stark
2003-12-16 20:51     ` Andre Hedrick
2003-12-16 21:04       ` Andre Hedrick
2003-12-16 21:46         ` Witold Krecicki
2003-12-16 20:09   ` Witold Krecicki
2003-12-16 21:11   ` Adam Kropelin
2003-12-16 21:25 ` jw schultz

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=1071657159.2155.76.camel@abyss.local \
    --to=peter@mysql.com \
    --cc=helgehaf@aitel.hist.no \
    --cc=jw@pegasys.ws \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mfedyk@matchmail.com \
    --cc=torvalds@osdl.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