On Tue, 12 Jun 2012 13:20:27 -0400 Thor Lancelot Simon <t...@panix.com> 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? <e...@math.uni-bonn.de> 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
