[Dovecot] NFS, IDLE, and index locking

[Jack Stewart]

Hi,

I'll try to keep short. My primary question is what, in people's 
experience, are the best configuration settings for to avoid potential 
NFS cache locking issues in an interesting heterogeneous environment? We 
appear to have a workaround for some locking issues we have seen, which 
is turning off IDLE. Upgrading our version of dovecot from 1.1.4 is 
likely to address some core issues, but I want to get the system setup 
in tune first. There are some things in our setup that seem dumb, and I 
would like to make sure they are dumb.

As far as our environment goes, it isn't unusual for our users to 
connect with multiple different clients from multiple locations. Some of 
these clients behave well, and some not so well. In addition we have 
multiple distributed servers with multiple instances. Generally the 
connection from one of their clients/desktops goes to the same server 
but their different desktops may connect to different servers.

If anyone has a similar enough environment, do you find it better to 
have the hard link setting off or is it better for you to turn it on?

The attribute cache is the default (60 seconds) which works well enough 
in a polling setting but may be a problem with IDLE (30 second check). 
Do you find it better to bump up the IDLE check interval or drop the 
attribute cache? Our cache and maildir are on separate NFS volumes so we 
can change one without changing the other.

Our tcp timeout setting is too long (it is the default). Do you find 
180-300 seconds more reasonable?


---Jack

To give some context, we have a handful of users with intermittent 
caching locking where the dovecot.index.cache file would simply not 
update. One of our internal people managed to get this problem when he 
was using pine (non-IDLE) with gnubiff (IDLE) from the same desktop. We 
haven't had any alarms since taking the brute force approach of turning 
off IDLE.

Unfortunately other projects are inhibiting my capacity for additional 
debugging at this time. Also, it isn't clear to me that we will learn 
anything useful since the servers do not appear to be tuned and they are 
only running dovecot 1.1.4.

Just for reference, below is our dovecot configutation.

disable_plaintext_auth = yes
base_dir        = /var/run/dovecot/imap-server-its/
protocols       = imap imaps
syslog_facility = local4
shutdown_clients = yes

ssl_cert_file   = xxx.pem
ssl_key_file    = yyy.key
ssl_ca_file     = zzz.pem

mail_location = 
maildir:/var/spool/maildir/%1Ln/%Ln:INDEX=/var/spool/dovecot/indexes/%1Ln/%Ln

login_greeting_capability = no
verbose_proctitle = yes
mail_debug = yes
imap_capability = "IMAP4rev1 SASL-IR SORT THREAD=REFERENCES MULTIAPPEND 
UNSELECT LITERAL+ CHILDREN NAMESPACE LOGIN-REFERRALS UIDPLUS 
LIST-EXTENDED I18NLEVEL=1"

# MAILDIR Performance settings
maildir_copy_with_hardlinks = yes
maildir_copy_preserve_filename = no

# Handling web logins & imap traffic
login_processes_count = 16
login_max_processes_count = 2048
max_mail_processes = 4096
mail_max_userip_connections = 2000

# NFS settings
mmap_disable = yes
fsync_disable = no
mail_nfs_index = yes
mail_nfs_storage = yes
dotlock_use_excl = yes

lock_method =fcntl


protocol imap {
   listen = *:10143
   ssl_listen = *:10993
   imap_client_workarounds = delay-newmail outlook-idle netscape-eoh
}

## Authentication processes

namespace private {
   separator = .
   prefix = Mail.
   inbox = yes
}

auth_verbose = yes

auth default {
   mechanisms = plain login

   passdb ldap {
     args = /etc/dovecot.conf-ldap
   }
   userdb static {
     args = uid=vmail gid=mail home=/var/spool/maildir/%1Ln/%Ln
   }

   socket listen {
     master {
       path = /var/run/dovecot/imap-server-its/auth-master
       user = vmail
       group = mail
     }
   user = root
}