Gvinum RAID5 performance

[Julian Elischer]

Brad Knowles wrote:

>  At 4:22 PM +1100 2004-11-01, Alastair D'Silva wrote:
>
> > The offshoot of this is that to ensure data integrity, a background
> > process is run periodically to verify the parity.
>
>
>  That's not the way that RAID-5 is supposed to work, at least not the
>  way I understand it. I would be very unhappy if I was using a disk
>  storage subsystem that was configured for RAID-5 and then found out
>  it was working in this manner. At the very least, I don't believe
>  that we could/should do this by default, and adding code to perform
>  in this manner seems to me to be unnecessary complexity.


You need the background task to read the blocks on the parity stripe 
because if
you only ever get good reads from teh data stripes and never read the 
parity stripe you
may grow bad sectors there which you will not detect until you need then 
and
by then its too late. It need sto be run at a very low priority however 
so as to not
interfere with production.

>
>
>  Keep in mind that if you've got a five disk RAID-5 array, then for
>  any given block, four of those disks are data and would have to be
>  accessed on every read operation anyway, and only one disk would be
>  parity. The more disks you have in your RAID array, the lower the
>  parity to data ratio, and the less benefit you would get from
>  checking parity in background.
it's not tha tyou need to verify the parity (though you should do that
too OCCASIONALLY) but that you need to rewrite any bad secors while you
can regenerate the data and not fail and THEN discover you can not read 
all the data.

>


> > I did notice that the read from a single drive resulted in that
> > drive's access light being locked on solid, while reading from the
> > plex caused all drives to flicker rather than being solid).
>
>

>
>
>  A "lazy read parity" RAID-5 implementation might have slightly
>  increased performance over normal RAID-5 on the same
>  controller/subsystem configuration, but the added complexity seems to
>  be counter-productive. If there is a hardware vendor that does this,
>  I'd be willing to bet that it's a lame marketing gimmick and little
>  more.

you certainly don't need to read the parity if you read good data from 
the disk
but you do need to read it on a regular basis.

>