On Sun, 16 Sep 2007, Ken Mandelberg wrote:
Our home directories are nfs mounted, and I read that mbx concurrency doesn't
work over NFS.
That is correct.
Don't use NFS to distribute mail. Especially, don't use NFS and IMAP
simultaneously.
Here's some of the gruesome details:
If you insist upon using NFS, then you are stuck with traditional UNIX
mailbox format and only one process at a time accessing the file. What's
more, NFS generally causes you to lose the "kiss of death" protection in
traditional UNIX mailbox format when more than one session tries to update
the file. In the non-NFS case, opening a new session causes the old
session to be killed. Since this generally does not work with NFS, both
sessions try to update, one wins and the other detects that it lost and
crashes. Hopefully it detects that it lost (the test is not 100%
perfect); because if the detection of its loss fails, it will corrupt the
mailbox file.
The only mutex in traditional UNIX mailbox format is an exclusive-access
mutex for writing the file. There is no mechanism in traditional UNIX
mailbox format by which multiple reading sessions can update the mailbox
and communicate those updates.
mbx and mix have such mechanisms. But, like the "kiss of death" mechanism
in traditional UNIX mailbox format, they don't stand much of a chance of
working over NFS. It will seem to work over NFS, but presently you'll
start encountering all the filesystem corruption.
Don't believe SUN's propaganda. NFS is not a real filesystem. It does
not have real filesystem semantics. Operations which are atomic on real
filesystems are non-atomic on NFS (e.g., the O_EXCL open mode).
Operations which are synchronized on real filesystems (e.g., data and
inode updates) are not synchronized on NFS. Last but not least, locks do
not work over NFS.
Would it work to just symbolically link ~id/INBOX to /var/mail/mbx/id.
Is /var/mail/mbx to be a locally mounted filesystem?
If so, I recommend doing something different. Create /var/mail/mbx as you
suggest, but instead of creating /var/mail/mbx/id as an mbx-format file,
create /var/mail/mbx/id/ as a *directory* owned by user id. Then, rewrite
routine mymailboxdir() in env_unix.c to be something like:
static char *mymailboxdir ()
{
char *home = myhomedir ();
/* initialize if first time */
if (!myMailboxDir && myHomeDir) {
char tmp[MAILTMPLEN];
struct stat sbuf;
sprintf (tmp,"/var/mail/mbx/%s",myusername ());
myMailboxDir = cpystr (stat (tmp,&sbuf) ? home : tmp);
}
return myMailboxDir ? myMailboxDir : "";
}
This way, non-INBOX mailboxes will also go in /var/mail/mbx/id/ and be
similarly protected from the evils of NFS.
Also, is imapd robust in dealing with failures in moving mail from the mbox
to the mbx due to out of space failures? For example will it only delete the
mail from mbox after a synchronous write succeeds to the mbx?
Yes, and yes.
If a large piece of mail is moved that partially succeeds does that corrupt
the mbx?
No. Partial moves are completely undone.
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
_______________________________________________
Imap-uw mailing list
Imap-uw@u.washington.edu
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
