Re: [exim] Autoreply database on NFS

Startseite
Nachricht löschen
Nachricht beantworten
Autor: Anthony de Boer
Datum:  
To: exim-users
Betreff: Re: [exim] Autoreply database on NFS
Philip Hazel wrote:
> On Mon, 27 Nov 2006, Anthony de Boer wrote:
>
> > The question is whether the reply-once database is NFS-safe. Tracing
> > through the code/docs/Google, it appears that the autoreply transport
> > will use tdb, and that tdb uses fcntl() locking, which should work (if
> > slowly) on NFS provided that locking support is available. Since
> > autoreply volume should be a drop in the bucket compared to normal mail
> > volume, performance implications shouldn't be an issue.
>
> If you have an NFS file store that is accessed by more than one host,
> the only safe locking technique is to use lock files. Using fcntl()
> isn't good enough. There is a long discussion about this in the comments
> in the code file src/transports/appendfile.c in the Exim source,
> starting around line 1483.


Unfortunately, that code is heavily embedded there and not available to
the once-database in autoreply.c.

High road: "hitching post" lockfile code copied into autoreply.c (or even
abstracted into a function everyone can use; there's already a second
copy in exim_lock.c for example). I can dust off my coder-fu if this
becomes necessary. I still have to see if the folks paying the bills
want this badly enough, and of course the sort of patch you'll accept
will weigh heavily too.

Middle road: it appears that since this is a recent Linux NFS client
talking to a Netapp, and therefore not the most broken NFS combination
ever seen, we *might* be able to trust fcntl() locking to actually work,
especially since this is off the most-used code path. Still chasing this
option down with local Netapp gurus to see if they're willing to take
responsibility for it working.

Low road: I could see doing a cheat whereby if the user has a vacation
autoreply configured, N-1 of the servers would 4xx any mail for him/her,
while the Nth keeps the autoreply database on local disk. Mail will
retry until it lucks into hitting the magic server. Hey, if the user's
really on vacation, they don't need timely delivery! :-) And yes, I'm
properly ashamed of myself for suggesting that.

--
Anthony de Boer