Re: raid0 slower than devices it is assembled of?

[Jörn Engel]

On Tue, 16 December 2003 13:11:25 -0800, Linus Torvalds wrote:
> On Tue, 16 Dec 2003, Mike Fedyk 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.
> 
> The thing you should try to do in parallel is the seeking, not the media
> throughput. And then small stripes hurt you, because they will end up
> seeking in sync.
> 
> For RAID5, you have different issues since the error correction makes
> updates be read-modify-write. At that point there are latency reasons to
> make the blocking be small.

Maybe I don't get it, but shouldn't large stripes help RAID5 as well?
For any write, you do the rmw stuff, so you have two seeks on two
drives, one of which is the parity one.  For RAID0, the same access
would result in one seek on one drive, but no fundamental difference.

With more than three drives, you should be able to parallelize the
seeks on RAID5 as well, shouldn't you?  So the same reasoning wrt long
stripes should apply, unless I'm stupid again.

Jörn

-- 
The competent programmer is fully aware of the strictly limited size of
his own skull; therefore he approaches the programming task in full
humility, and among other things he avoids clever tricks like the plague. 
-- Edsger W. Dijkstra
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/