Re: raid5 to utilize upto 8 cores

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.

quoted

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