SCSI drives recommendations

Bob Edwards Robert.Edwards at
Tue Jan 22 11:32:33 EST 2002

Steven Hanley wrote:
> On Mon, Jan 21, 2002 at 11:15:04AM -0000, Richard Cottrill wrote:
> > I think that kind of misses the point of what I was getting at. RAID5 is
>   good for making a big, reliable volume. It is not, however, very good at
>   'fast'. On a volume with many discs RAID5 is much more efficient (in terms
>   of capacity) than simple mirroring; but not as fast (those parity values
>   need to be calculated).
> I dont know that the calculation of parity is a slow down, I notice that when
> you insmod the raid5 module it does some tests with different code to see what
> speed it can do the parity calculations at.
> kernel: raid5: measuring checksumming speed
> kernel:    8regs     :   832.000 MB/sec
> kernel:    32regs    :   392.000 MB/sec
> kernel:    pII_mmx   :  1014.000 MB/sec
> kernel:    p5_mmx    :  1061.200 MB/sec
> kernel: raid5: using function: p5_mmx (1061.200 MB/sec)
> (from a dual 550 machine)
> so if the cacuations are happening even at a 10th the speed of this
> calcualtion there is no chance that that would be slowing things down.
>         See You
>             Steve

It's not calculating the parities that is the problem, as such, but getting
the data to calculate them from. If you have, eg. 4 disks in your RAID 5
and you want to write out a 1k block, the RAID system has to read the
pieces from each of the other disks, calculate the parity and then write out
new block and update the equivalent block on the disk doing parity for that

So, you would need 2 reads (no need to read the parity disk or the disk about
to be written to) and two writes.

If you have more than four disks, then your RAID 5 code might simply read in
old parity and the old data, infer the new parity from the old parity, old
and new data, and then write back to those two disks. Still 2 reads and 2

RAID 0 (slicing) would only need one write
RAID 1 (mirroring) would need two writes - but they can usually be done at the
same time.


Bob Edwards.

More information about the linux mailing list