Manuel Bouyer <bouyer@antioche.lip6.fr> writes:
> raid5 seems to suffer from bad performances, but I already noticed this
> with "external" raid5 arrays. With raid4 it seems possible to achieve
> performances close to ccd for reading, but writing is worse than
> raid5 ...

I'm kinda surprised that raid5 is substantially slower than raid4 for
reading...  Wonder why that'd be...  (I could believe disk caching...)


raid4 being slower than raid5 for writing isn't surprising; bottleneck
on parity disk, which is what raid5's layout was meant to address
(IIRC how the layours are laid out 8-).

worth noting that both write performance will depend greatly on the
amount of data you're writing in a chunk.

If you're writing a whole stripe of data at a time, i.e. updating all
of the disks in a single stripe at once, then you end up doine,
a.k.a. a "large write," you end up writing each data disk and each
parity disk once.  You end up increasing the cost of a write by (1/N),
where N is the number of data disks you have.

If you're doing a small write (i.e. writing less than a whole stripe),
you end up doing a read-modify-write, where you have to read the
parity and update it before writing the data out.  In the ~worst case,
that means you triple the cost of a write.  (instead of a single
write, you have to do read, then two writes.)

Very simplistic explanation, but it should be a start in the direction
of understanding the performance issues for the readers who don't
understand them.  8-)


I seem to recall that RF supports various schemes for decreasing these
costs (parity logging and chained declustering come to mind, but i was
never too deep into the RAID lingo).


I strongly recommend the RAID documents published by current and
former PDL folks.  (And no, that's not just a plug for a former
employer; i think they're interesting and worth reading.  8-)


cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.