http://dovecot.org/test/ Should work again with maildir. - Some bugfixes to indexes (possibly fixing the still persisting maildir sync errrors?) - Enabled cache file again. If client asks about something that can be cached for future, it's done. There's currently no smart logic about when not to do it or when to cache more than was asked for future use. Currently nothing is ever deleted from cache. Currently it's disabled if mmap_disable = yes. - Removed UIDPLUS extension after all. It needs more thinking with maildir, because for performance reasons new messages are given UIDs once at the end transaction rather than separately for each one. So, the UID would have to be 0 temporarily until transaction is committed. But the current API make the new messages visible without syncing, and then the sequences don't match anymore and we can't get the UIDs. So, this one needs thinking, mostly from API designing point of view. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20040621/26cfe747/attachment-0001.bin>
On Mon, Jun 21, 2004 at 05:52:09PM +0300, Timo Sirainen wrote:> http://dovecot.org/test/ > > Should work again with maildir. > > - Some bugfixes to indexes (possibly fixing the still persisting > maildir sync errrors?)Ah, gotta try that, but...> - Enabled cache file again. If client asks about something that can be > cached for future, it's done. There's currently no smart logic about > when not to do it or when to cache more than was asked for future use. > Currently nothing is ever deleted from cache. Currently it's disabled > if mmap_disable = yes....does that mean the cache-file will grow indefinitely?> - Removed UIDPLUS extension after all. It needs more thinking with > maildir, because for performance reasons new messages are given UIDs > once at the end transaction rather than separately for each one. So, > the UID would have to be 0 temporarily until transaction is committed. > But the current API make the new messages visible without syncing, and > then the sequences don't match anymore and we can't get the UIDs. So, > this one needs thinking, mostly from API designing point of view.Actually I find the current maildir-performance quite amazing when compared to courier or bincimap. The only other imapd that can hold a candle to dovecot (at least according to my little-bit-out-dated and not-so-representative personal benchmarks) appears to be cyrus. Anyways, as mentioned before, I'm still looking forward to the next Maildir-stable version. :-) regards
On Mon, Jun 21, 2004 at 05:52:09PM +0300, Timo Sirainen wrote:> http://dovecot.org/test/ > > Should work again with maildir. > > - Some bugfixes to indexes (possibly fixing the still persisting > maildir sync errrors?)Sorry, problemos still present. In addition to what I've seen before... sp dovecot: IMAP(moe): Maildir /home/moe/Maildir sync: UID < next_uid (312 < 314, file = msg.CDs4:2,) ...I'm now getting these, too: sp dovecot: IMAP(moe): Corrupted index cache file /home/moe/Maildir/.INBOX/dovecot.index.cache: indexid changed Over all it feels like the index screws up even more often than with the previous version. That could be just coincidence or wrong perception, tho.