On Thu, 2007-05-17 at 10:04 -0500, Troy Benjegerdes wrote:
But that's currently not *really* replicated. The real question I guess is why not use a cluster/distributed/san filesystem like AFS, GFS, Lustre, GPFS to handle the actual data, and specify that replication only works for maildir or other single file per message mailbox formats.
This already works, but people don't seem to want to use it. There are apparently some stability, performance, complexity and whatever problems. And if you're planning on replicating to a remote location far away they're really slow. But I haven't personally tried any of them, so all I can say is that people are interested in getting replication that doesn't require clustered filesystems, so I'll build it for them. :)
Then there are also these special users, such as me. :) I'm now running my own Dovecot server on the same server that receives my emails. I want to use my laptop from different locations, so I want to keep that working. But then again my desktop computer is faster than the remote server, so I'd want to run another Dovecot in the desktop which replicates with the remote server.
Then there are also people who would want to run Dovecot on their laptop and have it synchronize with the main server whenever network connection is available.
I also tend to have imap clients open on multiple machines, so the assumption that a user's mailbox will only be accessed from 1 IP is probably a bad one.
Yes, I know. But usually there's only one client that's actively modifying the mailbox. The readers don't need global locking because they're not changing anything. Except \Recent flag updates..
If a second dovecot gets a connection to a mailbox with a master lock, it would act as a proxy and redirect all writes to the master.
Actually this was my original plan, but then I decided that lock transfer is probably more efficient than proxying. But I'll add support for proxying in any case for accessing shared mailboxes in other servers, so if you prefer proxying it'll be easy to support too.
In the event that a master crashes or stops responding, the dovelock process would need a mechanism to revoke a master lock.. this might require some filesystem-specific glue to make sure that once a lock is revoked the dovecot process that had it's lock revoked can't write to the filesystem anymore. I can think of at least one way to do this with AFS by having the AFS server invalidate authentication tokens for the process/server that the lock was revoked from.
I was hoping to find an existing global lock manager. I think there exist some. If not, then I'll have to spend some more time thinking about it. Anyway everyone don't want to use AFS, so I can't rely on it :)