[Imap-uw] Simultaneous access to imap mailbox?

[Bob Atkins]

Mark,

While I have been acutely aware of the issues you describe below 
regarding the shortcomings of NFS and simultaneous imap access I don't 
see how to scale a large imap server environment without NFS. imap 
access is far more processor and memory intensive than nfs activity. 
Sooner or later we will exceed the capacity of a single server with 4+ 
CPUs and locally attached storage which by definition has no redundancy. 
Yes, we could upgrade to an Enterprise 10000 with 50+ processors but 
there are practical limits. The bottom line is that as imap exists today 
I don't see any way how to create service redundancy or scale beyond 
some limit of what a single server could provide without going to an 
extreme machine.

Am I missing something..... ???

Surely there are ways to code imap to work around the NFS locking 
issues, they may not be pretty but they would work.



Mark Crispin wrote:

> 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 at u.washington.edu
> https://mailman1.u.washington.edu/mailman/listinfo/imap-uw


-- 
*Bob Atkins * 
/President/CEO/

*DigiLink, Inc. <http://www.digilink.net>*
Business Inter-net-working
*/The Cure for the Common ISP!/*

	

Phone: (310) 577-9450
Fax: (310) 577-3360
eMail: bob at digilink.net

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman1.u.washington.edu/pipermail/imap-uw/attachments/20070916/da26e587/attachment-0001.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DigiLink_esig_logo.jpg
Type: image/jpeg
Size: 23605 bytes
Desc: not available
Url : http://mailman1.u.washington.edu/pipermail/imap-uw/attachments/20070916/da26e587/DigiLink_esig_logo-0001.jpg