v2.2.30 released

[Timo Sirainen]

On 31 May 2017, at 22.56, Joseph Tam <jtam.home at 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.