On 6/29/2011 1:10 PM, Daniel L. Miller wrote:
The parameters listed for nfs installations (mmap_disable, doctlock_use_excl, mail_nfs_storage, mail_nfs_index) - are they necessary for data integrity, and/or do they compensate for NFS latency and improve performance?
My understanding is the indexes are a critical part of a dbox storage, but on the other hand having local indexes is a major performance consideration. Is maildir a "better" choice under NFS than dbox?
Depends a lot on the latency and IOPS performance of the NFS server, the aggregate concurrent IMAP IO load, and also the inbound new mail delivery rate from the upstream MTA.
With either mbox or maildir you can put the indexes on fast local disk, SLC SSD being great for this, keeping a lot of random IO off the NFS server. This isn't possible with dbox storage since, as you noted, the index data is integral to the mail files. Corrupted mbox/maildir indexes are easy to fix, simply delete them and they're auto re-created.
Since maildir is IOPS heavy and NFS/GFS/OCFS don't seem to like high IOPS workloads that make heavy use of locking, mbox becomes very attractive due to it's very low IOPS demands. If you can live with the folder tree limitations of mbox, along with a higher probably of mailbox file corruption, mbox is likely the best format for NFS/GFS/OCFS.
Again, this all depends on the performance of the NFS server. If you have a properly configured NetApp filer you can probably do anything you want without limitation. If your NFS server is a home grown Linux or *BSD box that suffers high latency and/or low IOPS throughput, you're probably a good candidate for mbox and local index files.
Test such a configuration with both mbox and maildir using local indexes on fast loca disk or SSD. If you don't run out of IOPS with maildir it's probably preferable to mbox.
-- Stan