Re: [Exim] Washington mbx again

Etusivu
Poista viesti
Vastaa
Lähettäjä: Tom Samplonius
Päiväys:  
Vastaanottaja: Jeffrey Goldberg
Kopio: Nigel Metheringham, exim-users
Aihe: Re: [Exim] Washington mbx again
On Thu, 5 Oct 2000, Jeffrey Goldberg wrote:

...
> Would these complaints about UW-IMAP go away if it forced you to use mbx?
>
> -j


I doubt it. I found a rather useful discussion of the MBX issues on the
c-client list:

(From: Mark Crispin <MRC@???>)

> Is there some reason why the default type is not already mbx?


Yes, there is.

mbx is non-standard. c-client based applications are the only thing that deal
with it, and we strongly encourage application writes who want to create mbx
savvy programs to use c-client, to ensure interoperability. The downside of
this is that it shuts out applications that aren't based on c-client. That's
why the default in c-client is the crufty old format that UNIX has used for
the past 30 years.

mbx is not NFS-safe. mbx depends upon the UNIX filesystem semantics; in
particular, that locking works and the mailbox data is updated immediately and
consistantly.

In more detail, mbx uses random access I/O with multiple processes having
read/write access. mbx has four levels of lock:
1) open (shared lock)
2) open+parsing new mail (shared lock)
3) delivering new mail (exclusive lock - locks against lock 2)
4) open+expunging (exclusive lock - interlocks against locks 1,2,3)
These locks much be communicated properly with all processes which access the
mbx mailbox at all times. In addition, mbx will alter message flags in place
with a random access write() operation without any locking; this requires that
the buffer cache be updated immediately for all processes which have the
mailbox open. Delivery of new mail must immediately update the buffer cache
and the inode cache for all processes which have the mailbox open.

NFS makes none of these guarantees. There is a form of locking with NFS which
works if the phase of the moon is right and applications aren't exercising it
too much. mbx, to put it mildly, pummels locking. UNIX kernel locking for
local files can handle it, but NFS locking (if it exists) quickly collapses in
a catatonic heap (and with it, hangs the entire NFS cluster).