[Dovecot] NFS mail storage

[Stan Hoeppner]

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