<snip> >>> * All mail storage presented via NFS over 10Gbps Ethernet (Jumbo Frames) >>> >>> * Postfix will feed new email to Dovecot via LMTP >>> >>> * Dovecot servers have been split based on their role >>> >>> - Dovecot LDA Servers (running LMTP protocol) >>> >>> - Dovecot POP/IMAP servers (running POP/IMAP protocols) >> >> >> You're going to run into NFS caching troubles with the above split >> setup. I don't recommend it. You will see error messages about index >> corruption with it, and with dbox it can cause metadata loss. >> http://wiki2.dovecot.org/NFS http://wiki2.dovecot.org/Director > > > That might be the one thing (unfortunately) which prevents us from going > with the dbox format. I understand the same issue can actually occur on > Dovecot Maildir as well, but because Maildir works without these index > files, we were willing to just go with it. I will raise it again, but there > has been a lot of push back about introducing a single point of failure, > even though this is a perceived one. </snip>
I'm in the middle of working on a Maildir->mdbox migration as well, and likewise, over NFS (all Netapps but moving to Sun), and likewise with split LDA and IMAP/POP servers (and both of those served out of pools). I was hoping doing things like setting "mail_nfs_index = yes" and "mmap_disable = yes" and "mail_fsync = always/optimized" would mitigate most of the risks of index corruption, as well as probably turning indexing off on the LDA side of things--i.e. all the suggestions at http://wiki2.dovecot.org/NFS. Is that definitely not the case? Is there anything else (beyond moving to a director-based architecture) that can mitigate the risk of index corruption? In our case, incoming IMAP/POP are 'stuck' to servers based on IP persistence for a given amount of time, but incoming LDA is randomly distributed.