Recently moving to newer storage platforms for mailbox storage so looking at moving mounts from NFSv3 with lots of issues with locking and caching to NFSv4.
There seems to be a lot of benefits to v4 along with some other new features, namely “delegation”.
So the question boils down to, to delegate or not delegate on Maildir storage. There may be many reasons based on actual platform why to do (or not to do this), but I want to get the general opinion from others that may have more experience with this. Our setup is several FreeBSD 10.x clients running Dovecot/Exim, NetApp NFS mail storage (probably moving to TrueNAS) and using F5 load balancers for client side connections/SSL offload.
From what I’ve found (and what i’ve read in the RFC) is that delegation seems to work best when there is NOT a lot of file contention from clients accessing the same files. I realize that in some situations many people are using director to try and keep users on the same client; in our case we’re doing it with F5 iRules. The F5 iRules work great for POP3 and IMAP session persistence, but unfortunately that doesn’t work for SMTP and Dovecot LDA, so we still have possible race conditions from the MTA’s delivering into “INBOX”. (mostly dovecot indexes updating at the same time).
So the big question is, who is using Dovecot with maildirs with NFSv4 mounts. What has your experience been? Are you using delegation? By choice and why did you come to that decision.
I’m drawing up the conclusion that if you can *mostly* control client control to specific files (ie: directing access to a mailbox to come from one client), then delegation might be ok. However, if you’re not using director and have several NFS mail clients racing to access mailboxes, then delegation might turn into chaos.
Your comments welcome and appreciated.
-- Robert inoc.net!rblayzor XMPP: rblayzor.AT.inoc.net PGP Key: 78BEDCE1 @ pgp.mit.edu
Il 23/09/2016 14:31, Robert Blayzor ha scritto:
Recently moving to newer storage platforms for mailbox storage so looking at moving mounts from NFSv3 with lots of issues with locking and caching to NFSv4.
There seems to be a lot of benefits to v4 along with some other new features, namely “delegation”.
So the question boils down to, to delegate or not delegate on Maildir storage. There may be many reasons based on actual platform why to do (or not to do this), but I want to get the general opinion from others that may have more experience with this. Our setup is several FreeBSD 10.x clients running Dovecot/Exim, NetApp NFS mail storage (probably moving to TrueNAS) and using F5 load balancers for client side connections/SSL offload.
From what I’ve found (and what i’ve read in the RFC) is that delegation seems to work best when there is NOT a lot of file contention from clients accessing the same files. I realize that in some situations many people are using director to try and keep users on the same client; in our case we’re doing it with F5 iRules. The F5 iRules work great for POP3 and IMAP session persistence, but unfortunately that doesn’t work for SMTP and Dovecot LDA, so we still have possible race conditions from the MTA’s delivering into “INBOX”. (mostly dovecot indexes updating at the same time).
So the big question is, who is using Dovecot with maildirs with NFSv4 mounts. What has your experience been? Are you using delegation? By choice and why did you come to that decision.
I’m drawing up the conclusion that if you can *mostly* control client control to specific files (ie: directing access to a mailbox to come from one client), then delegation might be ok. However, if you’re not using director and have several NFS mail clients racing to access mailboxes, then delegation might turn into chaos.
Your comments welcome and appreciated.
Hi Robert,
we have a setup with (CentOS 6) Director+Dovecot, Maildir as storage on NetApp NFS v3. Every time I try to switch to NFS v4 I found issue with lock (and others). So for me NFSv4 with Maildir is "unstable" or need a fine tuning that I don't know.
-- Alessio Cecchi Postmaster @ http://www.qboxmail.it https://www.linkedin.com/in/alessice
participants (2)
-
Alessio Cecchi
-
Robert Blayzor