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.