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

[Greg Oster <oster%cs.usask.ca@localhost>]

On Tue, 12 Jun 2012 13:20:27 -0400
Thor Lancelot Simon <tls%panix.com@localhost> wrote:

> 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?

It's been a while since I've checked, and the current generation of 2TB
and 3TB disks may be significantly better than the 1TB disks... I also
don't know what the disks are doing with their write-back/write-through
caches these days either.  

> 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.

That, and someone would have to change the code :)

Later...

Greg Oster