On Jul 16, 2012, at 9:15 AM, Robert Schetterer wrote:
There where hot disputs relating such setups, read list archive
i guess nfs is simply not the ideal solution, however its used in real existing setups, also maildir may not ideal
for good advice there should be more info about how many mailboxes , how much traffic, mailbox size , loadbalancing solution etc
dont think exim is critical envolved in this ( but i dont know exim very good )
however someone from the list with equal setup may share his experience with you
as far i remember, Timo posted good advice also ,for nfs setups in the past
We're talking about tens of thousands of mailboxes and at least half a dozen servers involved. There is quite a bit of traffic. We've been running Maildir via NFS with another mailserver product for some time, and it's been ok as far as the shared file system standpoint.
I don't know why Maildir would be "not ideal". It seems to be the only option when it comes to NFS.
NFS is used extensively in our network and we already have a major investment with NetApp, and have been very happy with them.
The only issue I see right now is Dovecot index file write bashing if a user accesses their mailbox from multiple locations at the same time, and I gave that example in the previous post. That seems to be more and more common these days but still not the norm for 80%+ of the mailboxes we have.
From the MTA side of things, it looks like having Exim write directly into the ~/Maildir/new/ is the only sane choice since mail can be coming into a mailbox from a number of servers at the same time. We've used this extensively in the past with no issues.
We use a Brocade ADX to load balancing POP and IMAP sessions to the server. Stickiness doesn't really buy you anything on POP3 since a session connects, does it's thin and disconnects. IMAP on the other hand, I believe can have multiple connections open from the same client, so I think sticky would help. But neither of those help when the client is connecting from a different IP address.
Robert Blayzor INOC, LLC rblayzor@inoc.net http://www.inoc.net/~rblayzor/