Timo wrote:
+ If dovecot.index.cache corruption is detected, reset only the one
corrupted mail instead of the whole file.
Is this a big performance win? I still have users with jumbo mailboxes
who insist on direct mailbox file access using procmail or mail readers,
which trigger index rebuilds when dovecot accesses them.
What does Dovecot log then? But probably doesn't affect that. It's
only when Dovecot logs something about dovecot.index.cache corruption
that this helps.
It logs stuff like this
(Lots of this ...)
May 26 15:22:50 server dovecot: pop3(user): Warning: Transaction log
file /{cachedir}/dovecot.index.log was locked for 43 seconds (rotating while
syncing)
May 27 16:57:18 server dovecot: imap(user): Warning: Transaction log
file /{cachedir}/dovecot.index.log was locked for 105 seconds (Mailbox was
synchronized)
(... and some this this ...)
May 26 15:43:07 server dovecot: imap(user): Error: Next message
unexpectedly corrupted in mbox file /var/mail/user at 9627641
(... but very rarely this ...)
May 8 17:05:59 server dovecot: imap(user): Error: Corrupted index
cache file /{cachedir}/dovecot.index.cache: Broken virtual size for mail UID
12032 in mailbox INBOX: read(/var/mail/user): FETCH BODY[] got too little data:
6199 vs 6201
From what you say, the changes would only affects the latter, so no big change.
Thanks for the info.
Joseph Tam <jtam.h...@gmail.com>
