SCSI drives recommendations

[Robert Cohen]

Its not that calculating the parity itself is a bottleneck. Its getting the data
to calculate the parity with thats the bottleneck.
When a block is written, you need the data in matching blocks from every disk on
the system (except the parity block) to calculate the parity from.
So in a N disk system, to do a write of a block, you might need to do up to N-2
reads and 2 writes to the physical disks.
So basically getting speed relies on a big cache so hopefully you don't have to do
the reads too often. And basically raid5 is never going to be as fast as mirroring
(raid 1).

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
>
> --
> sjh at wibble.net http://wibble.net/~sjh
> Look Up In The Sky
>     Is it a bird?   No
>         Is it a plane    No
>             Is it a small blue banana?
> Yes