Locking Policy

[Bron Gondwana]

On Sat, 28 Mar 2009 13:40 +0000, "David Carter" <dpc22 at cam.ac.uk> wrote:
> On Sat, 28 Mar 2009, Bron Gondwana wrote:
> 
> > What I'm wondering is what other locking constraints are actually
> > codified?  I couldn't find anything about them grepping the doc
> > tree for obvious phrases (like... locking).
> 
> The only documentation that I've found is doc/internal/locking, which is 
> rather, um, minimal.

Maybe I'd better pad that out when I do some work on this.  I'm particularly
interested in stopping the "header doesn't exist" errors you get when
renaming a folder and having anther connection open to it - things like
that show that locking and reopening aren't coving 100% of cases properly.

> > It seems to me that a whole lot more locking should be happening on the 
> > header file, which along with strict ordering of locks and the removal 
> > of ACLs from the header file (we don't use them anyway) would mean we 
> > never get stupid issues like .index and .cache files being out of sync 
> > and needing the dodgy "sleep a second and see if the version numbers 
> > match" logic.
> 
> At the moment we need exclusive locks on two files as cyrus.header and 
> cyrus.index are both updated using a .NEW temporary file and a rename(), 
> which breaks the lock. Life would be much simpler if Unix provided a 
> primitive to both open and lock a file as a single atomic action.
> 
> I agree that a dedicated .lock file (which might be the header file if we 
> can move out the variable state) would be more elegant. We do however
> need 
> somewhere to store the mailbox UIDvalidity, user flag names and ACL, all 
> of which can change. UIDvalidity and flags names are critical, and the 
> user flag names can get quite large given 128 user flags. ACLs are less 
> critical, but I do like having a redundant copy of the ACL somewhere just 
> in case I ever needed to reconstruct mailboxes.db from scratch sometime.

Fair enough.  I guess the .header file is a sensible place.  So it sounds like
maybe a "cyrus.lock" file is the way to go.  And even a cyrus.poplock too.
It would be tempting to put the whole lot on a tmpfs, though the data/meta
partition split doesn't allow for a third base location easily!

> The exclusive POP lock on cyrus.cache is an additional complication, but 
> that is off to one side and seems to work reasonably well. (I'm not 
> entirely convinced that a server which implements delayed expunge
> actually 
> needs the exclusive lock, but it is mandated by RFC 1725, section 4).

It would need to lock something that prohibited the cyr_expire while the pop
connection was active, and besides - we move the record into cyrus.expunge,
that would be pretty messy to keep track of.

But why cyrus.cache?  It feels to me like it was used because it was there,
rather than actually having any semantic meaning.  Messy.

Bron.
-- 
  Bron Gondwana
  brong at fastmail.fm