Monolithic mailboxes.db?

[Dave McMurtrie]

Janne Peltonen wrote:

>Hi.
>
>We are going to upgrade to Cyrus v2.3 sometime before midsummer.
>Currently, we are running an old, old version of Cyrus with a plaintext
>mailboxes file. Now and again, an imapd process gets stuck and keeps the
>writelock on the mailboxes file - so we have to kill the stuck process
>manually before anybody else can complete any mailbox manipulation
>procedure. This is, needless to say, annoying.
>
>While planning this upgrade, my colleagues have been asking me whether
>the mailboxes database in current Cyrus is monolithic in the same way:
>if one process keeps a lock to one part of it, does it in fact have all
>of the file locked? To be more exact, is this the case with the Skiplist
>db format? We can't use berkeley because it doesn't work well with
>clustering and GFS (see previous posts on the subject, and pse don't
>tell me you can't cluster Cyrus).
>
>  
>
Cyrus doesn't use byterange locking for plaintext mailboxes.db.  It just 
relies on advisory locking of the whole file, and it updates the file 
atomically by creating a new version and renaming it.  Running 1.5.14, 
there used to be some locking issues where, much as you describe, we'd 
end up having to figure out which imapd wouldn't release the lock and 
kill it.  My previous employer  upgraded from a single server running 
1.5.14 with plaintext mailboxes.db to a cluster running 2.1.17 with 
plaintext mailboxes.db and is no longer experiencing those locking 
issues.  I can only assume that at some point between 1.5.14 and 2.1.17, 
Larry or Rob or Ken or someone fixed that problem.

Thanks,

Dave