On Jul 13, 2013, at 7:13 PM, Eric Sandeen wrote:
> On 7/13/13 7:11 PM, aurfalien wrote:
>> Hello again,
>> I have a Raid 6 x16 disk array with 128k stripe size and a 512 byte block
>> So I do;
>> mkfs.xfs -f -l size=512m -d su=128k,sw=14 /dev/mapper/vg_doofus_data-lv_data
>> And I get;
>> meta-data=/dev/mapper/vg_doofus_data-lv_data isize=256 agcount=32,
>> agsize=209428640 blks
>> = sectsz=512 attr=2, projid32bit=0
>> data = bsize=4096 blocks=6701716480, imaxpct=5
>> = sunit=32 swidth=448 blks
>> naming =version 2 bsize=4096 ascii-ci=0
>> log =internal log bsize=4096 blocks=131072, version=2
>> = sectsz=512 sunit=32 blks, lazy-count=1
>> realtime =none extsz=4096 blocks=0, rtextents=0
>> All is fine but I was recently made aware of tweaking agsize.
> Made aware by what? For what reason?
Autodesk has this software called Flame which requires very very fast local
storage using XFS. They have an entire write up on how to calc proper agsize
for optimal performance.
I never mess with agsize but it is required when creating the XFS file system
for use with Flame. I realize its tailored for there apps particular IO
characteristics, so I'm curious about it.
>> So I would like to mess around and iozone any diffs between the above
>> agcount of 32 and whatever agcount changes I may do.
> Unless iozone is your machine's normal workload, that will probably prove to
> be uninteresting.
Well, it will give me a base line comparison of non tweaked agsize vs tweaked
>> I didn't see any mention of agsize/agcount on the XFS FAQ and would
>> like to know, based on the above, why does XFS think I have 32
>> allocation groups with the corresponding size?
> It doesn't think so, it _knows_ so, because it made them itself. ;)
Yea but based on what?
Why 32 at there current size?
>> And are these optimal
> How high is up?
> Here's the appropriate faq entry:
Problem is I run Centos so the line;
"As of kernel 3.2.12, the default i/o scheduler, CFQ, will defeat much of the
parallelization in XFS. "
... doesn't really apply.