Question about 2.4.x mailbox rename/locking behaviour
Bill Ryder
bryder at wetafx.co.nz
Thu Aug 9 16:04:49 EDT 2012
Hi all,
We've been running cyrus for over a decade now but I have management that really wants to put in dovecot.
We have two problems with cyrus in our environment which is constantly used as ammunition against it.
We are running 2.3.16 right now.
The problems are
1. Can not unreserve a mailbox without restarting cyrus - these can be caused by number 2 below
2. Mailbox renames - or deletes - can take a LONG time - and delivery stops eventually.
The renames (and mailbox deletes which for us are renames into Trash) are the killer since the mailbox is locked during a move.
We have about a 1,000 users many of whom with 10 years of email. 100,000 emails in a folder is not uncommon.
A lot of our traffic is mailling lists and we deliver in batches of 50 to get a balance between hardlinking and parallelism, So
one locked mailbox in that batch hangs the entire batch.
Depending on fileserver load etc it can take 30 minutes to do one of these moves (artists often have wacom email folder drag and
drop events which can start huge unexpected mailbox renames) - in these cases if the mailbox is large I have to kill the imapd
doing the move and clean it up. This leads to a reserved mailbox that I can't clear without a reboot.
During these moves all dellivers into that folder lock up because cyrus.header is locked and the lmtp's try to get a lock on that
folder and they stop until postfix times out the delivery and defers it. Eventually we end up with a massive backlog because of
the batch delivers.
Has anything changed in 2.4 that will stop this kind of thing from happening?
I see in the release notes a lot of locking has been reworked. I didn't see anything about mailbox moves (I could have missed it).
We don't have separate filesystems so a directory rename would be the most efficient way for us to do the mailbox moves - but of
course cyrus is designed to handle a more general case and in 2.3.x it links the messages into the new destination folder and
unlinks them from the source which of course is the safe way to do it.
Has the mailbox rename code changed to do directory renames if the source and destination are on the same filesystem? That would
fix our problem.
(and yup - I realise there are more efficient things to use than mailling lists but I don't have control over that end of it)
Thanks!
Bill Ryder
Weta Digital
More information about the Info-cyrus
mailing list