Stan Hoeppner:
[ Charset ISO-8859-1 unsupported, converting... ]
> On 10/8/2011 5:17 AM, Wietse Venema wrote:
> > Stan Hoeppner:
> >> nicely. On the other hand, you won't see an EXTx filesystem capable of
> >> anywhere close to 10GB/s or greater file IO. Here XFS doesn't break a
> >> sweat.
> >
> > I recall that XFS was optimized for fast read/write with large
> > files, while email files are small, and have a comparatively high
> > metadata overhead (updating directories, inodes etc.). XFS is
> > probably not optimal here.
> >
> > Wietse
>
>
> With modern XFS this really depends on the specific workload and custom
> settings. Default XFS has always been very good with large file
> performance and has been optimized for such. It was historically
> hampered by write heavy metadata operations, but was sufficiently fast
> with metadata read operations, especially at high parallelism. The
> 'delaylog' code introduced in 2009 has mostly alleviated the metadata
> write performance issues. Delaylog is the default mode since Linux 2.6.39.
>
> XFS is not optimized by default for the OP's specific mail workload, but
> is almost infinitely tunable. The OP has been given multiple options on
> the XFS list to fix this problem. XFS is not unsuitable for this
> workload. The 10GB XFS filesystem created by the OP for this workload
> is not suitable. Doubling the FS size or tweaking the inode layout
> fixes the problem.
>
> As with most things, optimizing the defaults for some workloads may
> yield less than optimal performance with others. By default XFS is less
> than optimal for a high concurrency maildir workload. However with a
> proper storage stack architecture and XFS optimizations it handily
> outperforms all other filesystems. This would be the "XFS linear
> concatenation" setup I believe I've described here previously.
>
> XFS can do just about anything you want it to at any performance level
> you need. For the non default use cases, it simply requires knowledge,
> planning, tweaking, testing, and tweaking to get it there, not to
> mention time. Alas, the learning curve is very steep.
That's a lot of text. How about some hard numbers?
Wietse
