Re: RAIDframe performance vs. stripe size: Test Results

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

On Tue, 12 Jun 2012 17:02:21 +0200
Edgar Fuß <ef%math.uni-bonn.de@localhost> 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