When does Dovecot lazy expunge actually free quota and shrink the index under concurrent IMAP load?
0 reputation · 18 Jul 2020, 16:05 UTC
I'm evaluating whether to enable lazy_expunge = yes on a Dovecot 2.3.x server that hosts busy mailboxes in mdbox format. The documented behavior is clear in principle: expunged messages stay in storage and in the index until a later expunge pass, which avoids immediate disk I/O on the hot path.
What I cannot pin down is the practical timing. If deleted messages remain indexed, quota should not reflect the freed space right away, and the index should keep growing until doveadm expunge runs. But the documentation does not state whether mailbox close, a periodic plugin trigger, or only an explicit doveadm expunge -A actually processes the deferred removals, and how that interacts with many simultaneous IMAP sessions on the same mailbox.
I plan to verify with doveadm status -v counters and imaptest load, but before designing the test I want to understand the intended semantics.
Specifically: which events trigger processing of lazy-expunged messages in 2.3.x, and is it purely manual? Does concurrent access from multiple sessions delay or duplicate that processing? And is there a supported way to bound how much deferred-deletion storage accumulates before quota appears to recover?