Re: raid5 to utilize upto 8 cores

[Stan Hoeppner <stan@hardwarefreak.com>]

On 8/17/2012 6:47 AM, David Brown wrote:
> On 17/08/2012 12:52, Stan Hoeppner wrote:

> It sounds like I /have/ misunderstood things - at least regarding the
> inode64 allocator (which will surely be the best choice for a large
> array).  I had though that while directories "/a/" and "/b/" get
> different allocation groups, directories "/a/1/" and "/a/2/" would go in
> the same AG as "/a/".  What you are saying is that this is not correct -
> each of these four directories would go in a separate AG.  File "/a/1/x"
> would go in the same AG as "/a/1/", of course.  Assuming this is the
> case, XFS over linear concat sounds more appealing for a much wider set
> of applications than I had previously thought.

I may bear some blame for this.  Long ago I thought the inode64
allocator worked as you describe.  I may have spread that
misinformation.  If so, my apologies to all.

Indeed the inode64 allocator creates new directories evenly across all
AGs in a round robin fashion.  Thus it will work better with most
workloads on storage with some level of concatenation than with straight
striped RAID on rust.  This is due to excessive seeks across all the
AGs, which line up from outer to inner tracks when striping.  With SSD
seek starvation is irrelevant, so concat and striping are pretty much equal.

>> The only real benefit of striped RAID over concat, for the majority of
>> workloads, is $/GB.

To be more clear, I was obviously referring to striped parity RAID here,
not RAID10, which has the same cost as concat+mirror.

-- 
Stan