In reading the Dovecot NFS WIKI entry: http://wiki2.dovecot.org/NFS
It mentions a FreeBSD NFS client caching bug. I believe that bug only exists pre-8.x ? It seems that a patch in the PR notes was MFC'd and made it into 8.x at some point. (at least I checked the source in 8.3 and it was there). So I assume that FreeBSD 8.x mitigates the issue? Maybe not? So our deployment is multi server Dovecot/Exim running on FreeBSD servers, frontended by a layer3 load balancing switch and a NetApp NFSv3 datastore. The only real concern we have right now is race conditions and file write contention on the Dovecot index files. Our original plan was to use Dovecot LMTP on the servers to deliver to the inbox, but that doesn't seem to be recommended as we'll have a number of servers all acting as primary MX for domains and delivering to the same set of mailboxes. So are the Dovecot dotlock file locking mechanisms not enough for multiple servers trying to write/access index files in Maildirs? If we have to deliver straight to the ~/Maildir/new out of Exim, that's fine, also. We're just wondering if there is a added benefit of actually using LMTP. (other than making sure the index are kept the most recent). The other concern we have is client mailbox access. While we can make sessions "sticky" from one IP so they hit the same server, it doesn't help with the person that checks their email via POP from their PC while having their mobile phone access it via IMAP. (obviously from different IP addresses). So I guess there is some possibly index file write contention there as well. (though hopefully this should be rare). I'm curious as to know others experiences with a similar deployment. TIA -- Robert Blayzor INOC, LLC rblay...@inoc.net http://www.inoc.net/~rblayzor/
