Matthew B. Brookover wrote:
I have GFS up and running with UW-IMAP. Currently we are using the
mbox file format with version 2004g. We are looking at moving to MIX
some time next year. I have not done much MIX testing yet, but hope
to put it up on my test cluster when I have some time in December.
GFS is POSIX compliant. Flock, lock files, and fcntl locks work
across the cluster. Caches are kept synchronized, so a change to a
buffer on one node will show up in another. The biggest problem we
have had is when a user receives several hundred messages
simultaneously, the 3 mail servers will get hundreds of procmail
processes backed up waiting for the lock files.
We have a similar problem and it is not a function of GFS ... but any
system where each procmail needs a lock on the mailbox to deliver an
email. One solution we have been considering is having procmail
determine the number of already-running procmail processes for the user
in question. Above some thresshold, you could have procmail issue an
exit code that tells sendmail to shoot the messages into the queue.
This would potentially put some limit of the procmail concurrency issue
... but the side effect is more overhead per message delivery in general
to detect this situation.
I wonder if anyone has a more clever solution (other then switching to
an email folder format or server that does not have this locking issue
in the first place).
Mark ... I wonder if we can remove the explicit delivery locks we have
procmail use when one is using mix and dmail? Would that be advisable?
-Erik Kangas
LuxSci
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
