[OpenAFS] mail spool on AFS

Patrick J. LoPresti patl@curl.com
26 Nov 2001 13:02:30 -0500


Craig_Everhart@transarc.com writes:

> Excerpts from mail: 20-Nov-01 Re: [OpenAFS] mail spool on.. Patrick
> LoPresti@cag.lcs (1724*)
> 
> > Too bad you did not take one more step; you could have invented
> > maildirs and avoided the need for any locks at all.
> 
> > See http://cr.yp.to/proto/maildir.html, but my quick summary is as
> > follows:
> 
> > A maildir is a directory hierarchy that looks like this:
> 
> >         maildir
> >         maildir/tmp
> >         maildir/new
> 
> > To deliver a message, the MTA writes it as a new file under tmp, syncs
> > it, and renames it to put it under new.  Clients look for messages in
> > new, not tmp, so they never see any message until it has been fully
> > written.  This obviates the need for locks.
> 
> Not a bad idea.  But our solution, with locks, also prevents
> collisions between multiple simultaneous mail deliveries, as well as
> the occasional multiple simultaneous mail readers, not just
> single-threaded mail delivery vs. single-threaded mail reading.

Maildirs have no problem with concurrent deliveries; the MTA uses a
unique file name (timestamp.pid.hostname) for each message, so
independent MTAs will never collide.

Multiple concurrent readers only pose a problem if more than one of
them tries to *modify* the message simultaneously.  djb suggests
keeping flags (read/replied/forwarded/etc) in the file name, which
means that clients never need to modify the message itself.

You can still get "funny" behavior if two clients try to mark a
message as read simultaneously, as one of their attempted rename()
calls will fail.  But actual corruption of the message and flags is
still impossible because rename() is atomic.

You could also just have the client write a new file and rename() it
into place whenever it needed to alter the message; that would also
avoid any potential corruption.

 - Pat