On 31 May 2017, at 22.56, Joseph Tam <[email protected]> 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.
