On 7/14/2013 5:42 PM, aurfalien wrote: > My initial post on this was to try and understand if there mobs make sense to the general XFS community They do not. > and wether I could benefit from them in applying those mods to general purpose storage. You may or may not. There's simply not enough information available in that guide. Obviously Autodesk has a reason for recommending 128 AGs, but no such reasoning is provided. I already explained why, in the general case, agcount has no relevance in isolation. Setting agcount properly for the general XFS case requires knowledge of the underlying storage device size, geometry, spindle speed, etc. The Autodesk instructions Eric linked are specific to a select group of Autodesk certified HP workstation models, Autodesk's own storage arrays, or unspecified FC SAN storage. Nowhere in the "storage configuration" chapter does it mention the number of disks or RAID level required or recommended backing the LUNs. Thus, given what I've explained of the relationship between array capacity, spindle count, RAID level, etc, it simply doesn't make sense to arbitrarily specify 128 allocation groups, especially when the storage hardware characteristic are completely ignored. So if Autodesk is ignoring these critical factors when telling you to use 128 allocation groups, then they either have some application specific file layout that benefits from 128 AGs, or, as I said, they don't know XFS as well as they think they do. I'm not disparaging Autodesk here. There are plenty of vendors who do things with XFS that aren't necessarily wise, sometimes flat out bad. Taking a quick glance at the data directory layout on a current Flame system may get us closer to understanding why they want 128 AGs. For instance, if they've created exactly 128 directories on the XFS volume that would fully answer the question as to why they want 128 AGs. -- Stan _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
