Javier de Miguel Rodríguez put forth on 12/13/2010 1:26 AM:
Sadly, Red Hat Enterprise Linux 5 does not support natively XFS. Ican install it via CentosPlus, but we need Red Hat support if somethings goes VERY wrong. Red Hat Enterprise Linux 6 supports XFS (and gives me dovecot 2.0), but maybe it is "too early" for a RHEL6 deployment for so many users (sigh).
I will continue investigating about indexes. Any additional hint?
Dave Chinner is possibly the most prolific/active developer of XFS. He is the author of the XFS delayed logging code (up to 100x+ increase in matadata write throughput). He's a distinguished kernel engineer at Red Hat. I suggest you send an email to
xfs@oss.sgi.com
and ask to be CC'd on replies if you don't join the list.
Briefly, but concisely, describe your current mail storage setup including hardware (SAN topology and storage devices), software, mail box store format, average/peak concurrent user load, and what filesystem you currently use.
Then, save every reply you get and read them at least a couple of times each, thoroughly. You should then realize you're leaving a ton of performance on the table, eating far more resources than you should be, and generating more SAN traffic that what you would using XFS for the same workload, especially if you're able to use delaylog with a recent kernel. Delaylog pushes metadata operation loads almost entirely into memory, dramatically decreasing physical I/Os over the SAN, while simultaneously increasing throughput by an order or magnitude. For large maildir installations such as yours, you're almost committing a crime by using EXT3 and not XFS.
Sadly, until a major distro makes XFS its default enterprise filesystem, the bulk of the Linux world will have no clue what they've been missing for the past 7+ years, which is very sad. For any large parallel workload, XFS trounces EXT3/4/BTRFS/Reiser by a factor of 5-100+ depending on the exact workload.
-- Stan