On 31 May 2017, at 22.56, Joseph Tam <jtam.home@gmail.com> wrote:

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)

Not really an error, just bad performance.

(... 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

I guess caused by the direct access. I think not a big problem and won't cause cache corruption.

(... 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

This new feature would actually help with this. It would mark only the one mail corrupted in cache instead of everything.