Re: RAIDframe parity rebuild (was: RAIDframe performance vs. stripe size: Test Results)

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Tue, Jun 12, 2012 at 10:40:47AM -0600, Greg Oster wrote:
> On Tue, 12 Jun 2012 18:34:52 +0200
> Edgar Fu? <ef%math.uni-bonn.de@localhost> wrote:
> 
> > > So a parity rebuild does so by reading all the data and the
> > > exiting parity, computing the new parity, and then comparing the
> > > existing parity with the new parity.  If they match, it's on to the
> > > next stripe.  If they differ, the new parity is written out.
> > Oops.
> > What's the point of not simply writing out the computed parity?
> 
> Writes are typically slower, so not having to do them means the rebuild
> goes faster...

Are writes to the underlying disk really typically slower?  It's easy
to see why writes to the RAID set itself would be slower, but sequential
disk write throughput is usually pretty darned close to -- if not better
than -- read throughput these days, isn't it?

If you don't know the set's blank, I guess you do have to read the existing
data.  Maybe that limits how much win can really be had here.

Thor