Eric Rostetter put forth on 2/13/2010 8:39 PM:
This ignores the delivery of mail to the user (again, not so bad for maildir but a killer for mbox). If the delivery is on a separate box than dovecot your can have lock contention...
You attach the inbound MTA to the FC switch, export the LUN with the GFS2 filesystem and drop new mail to the appropirate folder(s). The dovecot cluster machines pick it up just as if it were on a local filesystem. This can be done very easily with with mbox or maildir and there's no more potential for lock contention than the imap files.
Also there may be other things to cause lock contention like backups, admin cron jobs to check things, etc.
You have all these things with a non clustered filesystem and have to deal with them there anyway, so there's really no difference is there? Is this much different than an IBM P595 with 64 Power6 5 GHz cores, 1TB of RAM, and 100TB of FasTt FC disk arrays, running a local inbound MTA (postfix), tens of thousands of imap processes handling concurrent users for a few million imap mailboxen? The only difference is lock data travels the wire outside the box in a cluster setup instead of through shared memory with the big SMP. You'll still have locking contention during backup etc, and probably more of it given the scale of this example. GigE is plenty fast enough to carry the small extra load of the cluster fs metadata. In fact, if the load balancing is implemented well, there will be very little locking contention at all, even during backup.
Anyway, I run dovecot in a cluster without any issue, but that is because of my client base and performance expectations (and some real nice hardware).
Tell us more about your hardware setup if you don't mind. General info, a brief few lines would be fine: load balancer, number/config of server nodes, SAN switch, storage arrays, software setup. Also, when do you plan to move to GFS2?
Thanks.
-- Stan