[Dovecot] dsync mbox->mdbox II: highest_modseq changed
Axel.Thimm at ATrpms.net
Fri Nov 19 08:40:41 EET 2010
On Thu, 2010-11-18 at 17:34 +0000, Timo Sirainen wrote:
> On Thu, 2010-11-18 at 18:57 +0200, Axel Thimm wrote:
> > dsync(athimm): Info: old/speicher: highest_modseq changed: 1 != 10
> > dsync(athimm): Info: root/root-heretic: highest_modseq changed: 1 != 10
> > dsync(athimm): Info: lists/ccrma.stanford.edu/planetccrma: highest_modseq changed: 11 != 14
> These don't really matter. It just couldn't sync the modseqs correctly.
> I should try to fix those somehow some day, but I think the problem here
> is that mbox code can't handle this correctly. It should have increased
> the modseqs to 10, 10, 14 but apparently it didn't.
Shouldn't it be the other way? mbox was the source, so its modseq should
had been considered authoritative, or not? One would expect that after
applying the (same) changes to mdbox that the modseq should converge to
be the same.
I'm just trying to understand whether the bug may be in the mdbox part
of the code. On another note I now switched to mdbox with bzip
compressed storage and everything seems nice and smooth. The server has
a much lower load when I connect and even the client I'm using
(evolution) which would previously crash due to timeouts is now working
much better (though still crashing, but that's not really related to
dovecot). The storage requirements have more than halved (15GB vs 34GB)
and are much easier to rsync/backup. I love mdbox. :)
http://thimm.gr/ - http://ATrpms.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://dovecot.org/pipermail/dovecot/attachments/20101119/33a3ca6e/attachment.bin
More information about the dovecot