I really like the maildir suggestion. 

The one problem that I see is that if you have mail.example.com pointing
to both client coda machines for pop/imap work, a message might be
delivered to one of them before the other, in other words theres a race
condition.

The user contacts 'mail.example.com' and it resolves to one of those
machine IP's to get mail, only to resolve again at the next interval to
find that its hit the other machine where it isnt all there yet.

Maybe inform half your users to use one machine regularly, and the other
half to use the other machine? Both client machines would still have all
sets of files, so you have the redundency in case theres a failure. But
the race condition is eliminated because users will normally only be
hitting their regularly assigned machine.

- lv

On Thu, 22 Apr 1999, Thiago Madeira de Lima wrote:

> 
> 
> I have 2 more informations that may be usefull to the solve :
> 
> 	1 - 60000 Mailboxes
> 	2 - We use procmail with separed dirs for each letter, like :
> 	
> 	/var/spool/mail/j/u/jungle
> 	/var/spool/mail/r/o/rox 
> 
> Changes anything?
> 
>  
> > jungle_at_sti.com.br said:
> > | We have here a mail system like this :
> > |   1 NFS Server (PII400 RAID5 and 128ram)
> > |   2 NFS Clients (pop/smtp) (PII900 SMP with 512Ram)
> > | 
> > | The clients mounts the /var/spool/mail partition of the server, and
> > | uses it for pop (cucipop) and smtp (sendmail/procmail).
> > |
> > | I'm considerin the use of coda, for performance reasons, and replicant
> > | servers. 
> > |
> > | My performance in using that configuration will be better with CODA?
> > | I'm seeing to many different oppinions about it, on the list. 
> > 
> > Well, the normal large unix mail files will make you hate life.
> > Although Coda will give local-disk read access once the file is fetched,
> > because of the write-write sharing and the fact that Coda caches on
> > a whole file basis, and needs to refetch the complete file everytime
> > it is modified on another machine, it won't be blazingly fast.
> > 
> > Besides you'll have 100's of file conflicts before you can say
> > ....that's fast...
> > 
> > There is no file locking, and even if there was, your coda clients
> > might decide it's a much nicer life being disconnected from the
> > overloaded servers and happily continue working without the pop-clients
> > seeing new email arriving.
> > 
> > On the other hand, there is the maildir format, an nice way of storing
> > mail in separate, uniquely named files, which is used by qmail. That way
> > there will be no `write-write' sharing on the filedata, and because of
> > how status flags are handled, any conflicts resulting from network, server
> > and client failures are in most cases resolvable directory conflicts.
> > (I think I got this url from the codalist one day:
> > 	ftp://koobera.math.uic.edu/www/proto/maildir.html)
> > 
> > If you had something like a 10-15 pop-users setup, it could be worth a
> > try. If you really need two 900MHz dual processor boxes to keep up with
> > the incoming traffic, no not yet. Wait until someone has actually tried 
> > and proved it to work on a small to medium scale setup.
> > 
> > Jan
> > 
> > 
>