> One thing the paper did not talk about at all was any
> parameters used in the build configuration or the mkfs/mount
> options used.
---
Good point.
>
> The correct mkfs options on xfs can make extents line up on
> stripe boundaries which helps I/O.
---
Yeah...just reading the mkfs.xfs manpage might help on that,
though if there are optimization issues not touched on there, I wouldn't
have expected them to do anything other than the 'default'.
Too bad mkfs doesn't or can't determine disk partition params
like a 'stripe size' to use in optimally setting default params
when formatting (or is mkfs smarter than I realize? That'd be way cool!).
> It also does not state the size of the test files in
> relationship to memory size - which makes the difference
> between reading/writing from cache and actually using the disks.
---
Hmmm...yeah...though I'd +hope+ to try something on the order of
copying a single multi-gig file, existing, alone, on a freshly formatted
RAID partition. There could also be variables in the per-disk cache
and RAID-card cache that'd I'd also hope would be negligible on a
all-out speed test (though accounting for those or best ways to optimize
for various disk-cache and RAID cache size at 'mkfs.xfs' time would be
even more arcana though even I would figure that setting stripe size
such that no 'write' exceeded an individual disk's write cache size
should have a positive effect on throughput).
>
> Since they talk about being almost cpu bound this would seem
> to indicate that anything in the code which could be turned
> off should be turned off to improve performance. In the case
> of xfs there are three things which will influence the
> performance, posix acls, quotas and dmapi. Turning each of
> these off reduces the code path. I am also not sure which
> code base was used for XFS, they say redhat 2.4.19 - which
> does not include XFS.
---
WAG, but I'd think they'd have gone with defaults or minimums --
if they wanted maximum throughput, I'd hope they'd turn off any
superfluous disk options. Given that they did more tests with xfs,
I'd almost guess they had a partiality to xfs and wanted to maximize
throughput on any of the filesystems used, since the primary purpose
of the testing wasn't to test the disks but to get maximum throughput
to test a 10-Gigabit network connection from Sunnyvale to Chicago.
I could see them not doing a "super thorough" job on disk param
setup since disks were secondary to their prime objective. I would
have tried something, using a block partition, raw partition or a
xfs-real-time section. RH not including xfs with their 2419 kernel?
Dang! Even SuSE is on their second xfs included release (first in
their 8.0, which contained 2418, I believe).
(Parenthetically speaking: any ideas on when we might see xfs
in a vanilla stable series or is that still in the "nobody's looked
at that yet", phase?)
> So all in all, my conclusion is there is too little
> information here to deduce what might be possible with the hardware.
---
Yeah...though I haven't run into any definitive tests, so far, in
my semi-random, non-thorough, net readings.
BTW -- my list email is indeed screwed. Got all the 'cc's, but
none of the message copies sent to the list. Very peculiar -- since
I'm seeing _no_ emails from outside my domain that don't me in
the "To" line. Seems to not be making it
to my ISP...my logs indicate the emails never make it into their
'in queue(s)' for my address. Very weird. Also annoying is that
I don't see bounce messages (if any).
Thanks for everyone's detailed deconstruction of the benchmark's
shortcomings. I should try to see if that person has tried anything
newer since that test...
Linda
|