On Fri, May 18, 2007 1:10 pm, Timo Sirainen <tss@iki.fi> said:

On Fri, 2007-05-18 at 12:20 -0400, Bill Boebel wrote:

...

So what about tackling this replication problem from a different angle... Make it Dovecot's job to replicate the index and control files between servers, and make it the file system's job to replicate just the mail data. This would require further disconnecting the index and control files from the mail data, so that there is less syncing required. i.e. remove the need to check directory mtimes and to compare directory listings against the index; and instead assume that the indexes are always correct. Periodically you could still check to see if a sync is needed, but you'd do this must less frequently.

This would practically mean that you want either cydir or dbox storage.

This kind of a hybrid replication / clustered filesystem implementation would simplify the replication a bit, but all the difficult things related to UID conflicts etc. will still be there. So I wouldn't mind implementing this, but I think implementing the message content sending via TCP socket wouldn't add much more code anymore.

The clustered filesystem could probably be used to simplify some things though, such as UID allocation could be done by renaming a "uid-<next uid>" file. If the rename() succeeded, you allocated the UID, otherwise someone else did and you'll have to find the new filename and try again. But I'm not sure if this kind of a special-case handling would be good. Unless of course I decide to use the same thing for non-replicated cydir/dbox.

Dbox definitely sounds promising. I'd avoid putting this uid-<nextuid> file in the same location as the mail storage though, because if you can truly keep mail storage isolated and infrequently accessed, then you can do cool things like store your mail data remotely on Amazon S3 or equivalent.