[Dovecot] Replication plans

[Timo Sirainen]

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 :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://dovecot.org/pipermail/dovecot/attachments/20070517/c1e8b7c1/attachment.pgp