On Tue, 2013-04-16 at 12:38 +0200, Thomas Hummel wrote:
On Thu, Apr 11, 2013 at 01:09:18PM +0300, Timo Sirainen wrote:
the user may see an incorrect state for a small amount of time, doesn't he ?
[...]
For a small amount of time, yes.
[...]
Which is probably a few seconds, so I don't see this as much of a problem.
Well, isn't, as with rsync, the travel time through the filesystem (to find out what's to be sync'ed) incompressible, in which case it would take more than a few seconds on a large mailbox (I'm testing but in more complex conditions) ?
Is dsync, for that matter, fastest than rsync (maybe because using dovecot-uidlist or similar) ?
dsync doesn't scan through filesystem. It reads the changes from the index files. If there are no changes it's pretty much instant even with 1M mail mailbox. With changes it's still fast enough (and could be faster still by using incremental syncing with saved state via -s parameter).
Besides, how about client side indexing while in this incoherent, not yet fully sync'ed state ? Wouldn't there be corruption risk ?
The worst that can happen is:
- Client sees new mail 123 in old server
- Client sees only mails up to 122 in the new server
- Client again will see mail 123 after a while
I'm actually not sure how clients will handle that. It is an IMAP protocol violation. It would be possible to add a new flag to dsync where it would treat all new emails as conflicts and give them new UIDs, so in the above case it wouldn't save a mail 123 but 124.