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