On Tue, 12 Jun 2012 17:02:21 +0200 Edgar Fuß <e...@math.uni-bonn.de> wrote:
> > Any comments on the results? > Really no comments? > Parity re-build: > 32 8 128 > 6min ~15min <5min > > My questions: > > Why does parity re-build take longer with smaller stripes? Is it > > really done one stripe at a time? 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. No, this doesn't happen one stripe at a time -- it's much more parallel than that. What we don't know here is what the state of the array was when you started the rebuild. That is, was the parity 'mostly correct' beforehand? (i.e. saving having to do a lot of the writes). If it really was doing one write per stripe, then it can still be much slower with the smaller stripes -- there's way more overhead, and the amount of work getting done with each IO is much smaller.... > > Why does enabling quotas slow down extraction so much? The test > > data should be ordered by uid in the tar, so quota should be easily > > cachable. Why does the negative impact of atime updates decrease at > > larger block/stripe sizes? > No answers to my questions either? I don't know the answers to these questions. Later... Greg Oster
