MESSAGE quota resource implemention

[Bron Gondwana]

On Mon, Sep 05, 2011 at 07:19:00PM +0200, Julien Coloos wrote:
> Le 05/09/2011 12:06, Bron Gondwana a écrit :
> >On Mon, Sep 05, 2011 at 02:32:40PM +1000, Greg Banks wrote:
> >
> >>  - add a 32b mailbox index header entry to track the storage in bytes
> >>used by all annotations for the mailbox itself or for messages in the
> >>mailbox
> >Why not 64b?  Admittedly hanging gigabytes of annotations off a single
> >folders is probably evil, but this is the mailbox header - 4 bytes per
> >mailbox to not even have to think about it is super-cheap.  We keep a
> >handful of "blanks" around in the header already.
> >
> >...
> >
> >>  - in mailbox_commit_quota(), if the field is not "unknown", then
> >>calculate the delta in usage and apply to the quota db.
> >
> This new field seems useful for the quota utility and when setting a
> new quotaroot: it wouldn't need to check each annotation associated
> to the mailbox (or messages) and would rely on that field, as it
> currently does for total message size and now the number of messages
> (with my patch).
> I don't know what other people do with cyrus, but here those two
> situations do not happen that often:
>   - quotaroot is usually set once upon creating the user mailbox
>   - quota utility is rarely used, and usually on one mailbox at a time
> So maybe I am missing something, but my question would be: is it
> really worth it ?

I would challenge the "usually on one mailbox at a time" theory - it's
often on one quota root at a time (i.e. - a single user), but also can
be used on the entire server.  Or for someone with a domain quota, on
all the users in a single domain.

This can be quite the race condition if someone has a lot of mailboxes
and a lot of traffic on said mailboxes.  Short of killing their
connections and blocking LMTP traffic, you can't guarantee atomicity
on actions that cross multiple mailboxes.

But - the new field definitely has value.  I like the idea of just
trusting that field in the quota utility and for regular tasks.

Bron.