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. -- Stan
