[Dovecot] NFS performance and 1.1.3 - what can you (unofficially) get away with?

Jack Stewart jstewart at caltech.edu
Wed Sep 10 20:58:37 EEST 2008


Hi,

Does anyone have experience with bending the NFS recommendations to get 
better performance?

The question is has anyone, with Maildir and the INDEX= on NFS (i.e. 
dovecot.index and dovecot.index.cache, set mail_nfs_index to no. If so, 
was it better to turn maildir_copy_preserve_filename to on or did it 
help to turn if off. The other question is did you play with turning off 
atime updates or changing the acmin* values?

I know that the recommendation is do not do this. Fortunately Timo's 
screams won't reach my ears for another ten hours. I'm just interested 
if anyone has done this. You are most welcome to reply offline.

I figure that the worst that can happen is that the dovecot.index.cache 
file will become corrupt, and dovecot will then rebuild it. As long as 
this doesn't happen all the time, it should not be a big deal. I'm 
guessing that this is less likely maildir_copy_preserve_filename turned 
on. My old (courier) servers is that I was able to get away with 
disabling atime updates and bumping up acmin* but then there was no 
central index to check.

I admit that this is a nutty way to go since part of the whole point of 
1.1.X is its NFS settings. Yet this is a place with some pretty nutty 
users. (i.e. 2+GB inboxes, 100K messages, one/minute connections, ...)

---Jack

P.S. As a total aside people migrating from 1.0.X to 1.1.3 may wish to 
have to use a different INDEX directory in 1.1.3 than the one you used 
in 1.0.7. Doing this got rid of my index.cache and transaction log error 
messages. This may be why testing isn't showing anything.

P.P.S. I've tried imapproxy for my webmail but it doesn't seem to have 
made much of a difference on the INDEX I/O.



More information about the dovecot mailing list