No subject

Curious, are those Intel, OCZ, or other SSDs?  Which model,
specifically?  Benchmark data?  I ask as all the results I find on the
web for SSDs are from Windows 7 machines. :(  I like to see some Linux
results.

>> AG count has a
>> direct relationship to the storage hardware, not the number of CPUs
>> (cores) in the system.
> 
> Actually, I used 16 AGs because it's twice the number of CPU cores
> and I want to make sure that CPU parallel workloads (e.g. make -j 8)
> don't serialise on AG locks during allocation. IOWs, I laid it out
> that way precisely because of the number of CPUs in the system...

And that makes perfect sense, assuming you have a sufficiently speedy
storage device, which you do.

> And to point out the not-so-obvious, this is the _default layout_
> that mkfs.xfs in the debian squeeze installer came up with. IOWs,
> mkfs.xfs did exactly what I wanted without me having to tweak
> _anything_.

Forgive me for I've not looked at the code.  How exactly does mkfs.xfs
determine the AG count?  If you'd had a single 7.2k SATA drive instead
of 2 RAID0 SSDs, would it have still given you 16 AGs?  If so, I'd say
that's a bug.

>> If you have a 24 core system (2x Magny Cours)
>> and a single disk, creating an FS with 24 AGs will give you nothing, and
>> may actually impede performance due to all the extra head seeking across
>> those 24 AGs.
> 
> In that case, you are right. Single spindle SRDs go backwards in
> performance pretty quickly once you go over 4 AGs...

That was the point I was making originally.  AG count should be balanced
between storage device performance and number of cores, not strictly one
or the other.  True?  How does mkfs.xfs strike that balance?  Or does
it, if using defaults?

-- 
Stan