On 2013-05-03 1:30 AM, Stan Hoeppner stan@hardwarefreak.com wrote:
From a filesystem perspective mdbox is little different from maildir as they both exhibit lots of small random IOs.
Hi Stan. Thanks, was hoping you'd chime in here...
But, I'm confused as to why you'd say this. mdbox supposedly has many advantages over maildir, since it is *not* a single file for every email (like maildir or sdbox).
My recommendation is to use XFS with the defaults, but add "inode64" to the mount options in /etc/fstab. This enables the modern allocator which clusters files around their parent directory within an allocation group. It's the default allocator in very recent upstream kernels but not in most currently shipping distro kernels. It decreases seek latency between metadata and file operations, and better manages on disk space. In short, XFS will yield superior mail performance to EXT4 in a multiuser environment.
Thanks very much. I'd already come to a similar conclusion, but was starting to have doubts after some of the prior comments. But what you say backs up the majority of what I've been reading. It's just difficult to judge what you're reading when you aren't a software or hardware engineer, just a lowly self-taught sysadmin who still consider himself a noob even after doing this for a few years.
There are currently no mail workload tuning docs in the world of XFS that I'm aware of. I've been intending to write such a doc for the XFS.org FAQ for some time but it hasn't happened yet.
Hope you find the time to do it some day... :)
On 2013-05-03 5:54 AM, Stan Hoeppner stan@hardwarefreak.com wrote:
Many XFS mount options are kernel version specific. Show: ~$ uname -a
Linux myhost 3.7.10-gentoo-r1 #3 SMP Sat Apr 27 10:01:59 EDT 2013 x86_64 AMD Opteron(tm) Processor 4180 AuthenticAMD GNU/Linux
Delaylog doesn't exist in recent mount(8) because it's no longer a mount option, same goes for older mount(8). Its existence as a mount option didn't exist for long, WRT distro mount(8) updates. Since 2.6.39 delaylog is the default, and as of somewhat more recently in the 3.x tree, the old journal logging code was completely removed from the source. Thus there is no longer a "delaylog" mount option. The feature is now hard coded in XFS.
Got it, thanks.
Barriers are crucial to XFS journal, and thus filesystem, reliability. "nobarrier" isn't listed in mount(8), though "barrier" is, which is the default mode. Making people "look for" the switch that disables barriers forces them to take a learning journey. Hopefully during this journey they become educated to the risks of disabling it, before doing so. "Better reliability through obscurity" you might say. Consider the horrible rap XFS would have today if everyone and his dog could easily learn how to disable barriers, then did so on hardware not appropriate for it. Yes, exactly, corrupted XFS filesystems littering the landscape and people screaming what a pile of dogsh|zt XFS is.
Got it, thanks again.
WRT noquota, it is the default. You'd never specify it. There are 10 quota options at the bottom of the XFS section of mount(8) that one might want to set.
It is quite irritating, yet surprisingly common, to see XFS users re-specifying the defaults in their /etc/fstab, because they didn't take the time to educate themselves properly, and simply copy/pasted from one of many online "XFS tuning guides". On the XFS list we call these "XFS mis-tuning guides", as nearly all of them contain mostly misinformation. Not intentional mind you, but because they just don't know what they're talking about, or they did but the guide is 5+ years old, and things have changed.
Ok, so here's my final fstab... thanks again for all of the comments (especially yours Stan).
# <fs> <mountpoint> <type> <opts>
--
Best regards,
Charles