On Tue, 4 Mar 2008, Timo Sirainen wrote:
On Feb 22, 2008, at 9:42 AM, Gerhard Wiesinger wrote:
Hello Timo! Looks like that mbox index handling still doesn't work with deliver: 1.) 1s mail delivered: Only dovecot.index.log is generated.
This is correct. dovecot.index doesn't need to be created/updated always, and dovecot.index.cache isn't created because there's nothing that's known wanted to be cached.
Hmmm. But shouldn't this be a feature of 1.1 that deliver updates indexes at deliver time? (maybe you can choose the typical indexes the clients use).
Updating dovecot.index.log is enough. v1.0 unneededly wastes disk I/O writing to dovecot.index way too often.
I don't think this is wasted disk I/O updating indexes as soon as possible. When the mailbox (mbox) is read afterwards on large mboxes there is much more waste in reading large files.
e.g. When deliver would write e.g. 3 mails with 40 MB: 1.) with indexes write large mailbox update small index
reopen: only read small index
2.) without indexes write large mailbox
reopen: read large mailbox update small index
So case 1 with indexes is IHMO in total more efficient.
- deliver the first mail
- open the mailbox
- deliver lots of large mails
- open the mailbox again
It should be fast. (and I just tested - it is)
Yes, that's exactly the testcase I use. But here it is slow (opening is always done with doevecot 1.0.latest/alpine 1.00 and deliver is done with 1.1.rc1). I use large files to see a time I see on the first look on opening.
Check with v1.1's idxview what the index file contains after steps 2, 3 and 4. After step 2 it should contain for the first message all the cached fields that client needs. Between 3 and 4 steps there should be no changes, and the cache fields should be exactly the same with the same decision rules as with step 2.
I will check that.
Ciao, Gerhard