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?
> [EMAIL PROTECTED] 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
>
>
