From: Stan Hoeppner <stan@hardwarefreak.com>
To: aurfalien <aurfalien@gmail.com>
Cc: Eric Sandeen <sandeen@sandeen.net>, xfs@oss.sgi.com
Subject: Re: specify agsize?
Date: Sun, 14 Jul 2013 18:43:56 -0500 [thread overview]
Message-ID: <51E337BC.3090304@hardwarefreak.com> (raw)
In-Reply-To: <2869A4A3-909A-486D-90A2-C1B04317EA40@gmail.com>
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@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-07-14 23:43 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-14 0:11 specify agsize? aurfalien
2013-07-14 2:13 ` Eric Sandeen
2013-07-14 4:20 ` aurfalien
2013-07-14 7:06 ` Stan Hoeppner
2013-07-14 16:56 ` aurfalien
2013-07-15 1:07 ` Dave Chinner
2013-07-14 16:14 ` Eric Sandeen
2013-07-14 16:46 ` aurfalien
2013-07-14 17:14 ` aurfalien
2013-07-15 1:22 ` Dave Chinner
2013-07-14 22:08 ` Stan Hoeppner
2013-07-14 22:42 ` aurfalien
2013-07-14 23:43 ` Stan Hoeppner [this message]
-- strict thread matches above, loose matches on Subject: below --
2013-07-14 19:45 Richard Scobie
2013-07-14 22:18 ` aurfalien
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51E337BC.3090304@hardwarefreak.com \
--to=stan@hardwarefreak.com \
--cc=aurfalien@gmail.com \
--cc=sandeen@sandeen.net \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox