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 -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
