Re: [exim] heartbeat load balancing and exim

On 2008-04-17 at 21:46 +0200, Wouter Verhelst wrote:
> Doing mbox over NFS is a bad idea regardless of whether you use exim or
> something else. If/when you want to do mail on NFS, Maildir is much
> better. This is nothing exim-specific.

With multiple clients, every change to the contents of a directory
invalidates the caches of the clients other than the one which made the
change; a format such as Maildir will increase the amount of background
traffic once more than one machine is looking at the contents of a
particular directory and heavily increase the metadata workload of the
NFS server. Not many NFS servers can survive the metadata-heavy
workload of a busy mail-system when using file-per-mail, particularly
not when just reading the file can rename the file. I managed to
demonstrate failure of some rather expensive kit and cause it to fail
acceptance testing because the big-name vendor had underestimated how
heavy a workload this is.

The perceived problem with mbox is that it requires robust file-locking
to be safe. If you're already having to limit the number of machines
accessing a given directory, the risk of locking malfunction goes down
as you've reduced the cross-machine lock operations.

Not that I'd want to do either again. My point is that your absolute
statements about what's better are dubious at best.

Exim was rarely the source of our problems with NFS though, provided
that the local spool is _not_ on NFS and is deliberately kept as small
as possible (ideally no messages lingering in the spool for more than
milliseconds).

I think that if your system has scaled to the point where you're having
to consider which feature breaks more easily (locking, server metadata
update handling, something else) then (a) you've already lost and (b)
mailing-list absolutist commentary is only going to show up the
prejudices of the person commenting, you'll have to do your own tests.

-Phil