On Tuesday 26 April 2005 22:44, Timo Sirainen wrote:

On Tue, 2005-04-26 at 14:13 -0700, Dan Stromberg wrote:

...

Is dovecot still considered unreliable when combined with NFS?

Is this true for mbox only, or Maildir as well?

If dovecot Is still considered unreliable with NFS, how about having a dovecot mode that would chain into procmail for delivery, so that dovecot doesn't (necessarily) have to reinvent that wheel?

I'm not sure what Procmail has to do with NFS unreliability. You can use Procmail to store the incoming messages, but the problems come when mailbox is actually being accessed with IMAP/POP3.

The problem isn't in either mbox or maildir, it's Dovecot's index files. It's of course possible to store indexes to local disk, but if you're using multiple servers you'll get worse performance whenever latest indexes can't be used.

Recent 1.0-tests should be somewhat usable with NFS too. I think someone in this list already is using it.

Yep we are, NFS server with 2x dovecot servers, mailboxes are Maildir and indexes are stored on local HDDs. Using Mysql master-slaves for user/pass.
Very reliable system, only real problem we had was when the NFS HDD failed.
We now have a redundancy for that too :) Timo has done some great work to get this kinda thing working.

Regards Andrew

Andrew Hutchings (A-Wing) Linux Guru - Netserve Consultants Ltd. - www.domaincity.co.uk Admin - North Wales Linux User Group - www.nwlug.org.uk Proprietor - A-Wing Internet Services - www.a-wing.co.uk Random BOFH excuse: IRQ dropout

On Wed, Apr 27, 2005 at 12:44:47AM +0300, Timo Sirainen wrote:

The problem [with dovecot and NFS] isn't in either mbox or maildir, it's Dovecot's index files. It's of course possible to store indexes to local disk, but if you're using multiple servers you'll get worse performance whenever latest indexes can't be used.

Recent 1.0-tests should be somewhat usable with NFS too. I think someone in this list already is using it.

We've actually been using Dovecot with mailboxes (both mbox and maildir) stored on NFS mounts. Only a few people use it regularly, so far, but we haven't seen any issues lately. I think, anyway :) Index files are stored on local disks, and yet we're using multiple servers; the layer-4 ethernet switch (which does the balancing between servers) tries to send new connections from the same IP address to the same server, in order to re-use the indices.

Maildir is supposed to be NFS-safe anyway, no locking required; renames (and other metadata updates) are supposed to be atomic even over NFS, and they certainly are in the case of our NFS setup (which has grown to 4 NetApp Filers and ~70 FreeBSD clients -- with sendmail, procmail, qmail-pop3d, UW-IMAP, uqwk, elm, mutt, pine, dovecot, the whole lot as clients.) We've been using the same setup to handle quite a lot of email for quite a lot of years.

'mbox' mailboxes do need to be locked, though; 'dotlocking' is considered the only reasonable way to lock over NFS, and both Dovecot and Procmail support this. (You can actually use fcntl/flock over NFS if the server and client both support lockd, but good lockd implementations are scarce and even the good ones suffer greatly from the locking deficiency in NFS; NFS doesn't support locking very well, because it's essentially stateless, and locks are by definition state. lockd tries to work around this, but it has complications. Crashed servers leaving unbreakable locks until those servers return, for instance.)

When compiling procmail, you may want to tell it explicitly to use dotlocking (by defining all of NO_fcntl_LOCK, NO_lockf_LOCK and NO_flock_LOCK, in config.h). Procmail's locktest isn't completely reliable as on some systems, flock/fcntl/lockf may actually seem to lock properly -- locally, even without lockd -- but the lock won't be propagated over NFS and so it's completely useless. However, if you run procmail's locktest (and tell it on which NFS filesystems to test) and it tells you:

/* Procmail will lock via: dotlocking */

... it all should work.

-- Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!