MESSAGE quota resource implemention

Julien Coloos julien.coloos at atos.net
Wed Sep 7 10:45:43 EDT 2011


Le 06/09/2011 10:23, Greg Banks a écrit :
>
> a) my commit "Make quota -f less racy" is going to cause lots of clashes
> (sorry!)
>
> b) Bron and I both think that your commit "Compute each quota resource
> upon setting it for the first time." is unnecessary, given that
>
>    i) quota -f doesn't suck now, and
>
>    ii) soon, all of the quota-able quantities will be tracked in fields
> in the index header.
>
> So I think we'll need another round, sorry :(  Given that the
> annotations quota is broken and I'll be reimplementing it anyway, you
> may as well ignore QUOTA_ANNOTSTORAGE in all commits, and leave out the
> function annotatemore_computequota() for now.  We'll use something very
> much like it for reconstruct later.  I'm hoping to be able to pull your
> next round of changes into my annotate branch before I reimplement the
> annotation quota in the next few days.
>
> ...
>
> I'm still not convinced we'll need quota.sets[], but I'll play along.
>
> Thanks again for your work, and sorry that my annotate branch wasn't
> quite as stable a base as you first thought :)
So, I saved my current branch to 'quotamessage-0/gnb/annotate' and 
rebased my patches on current 'annotate' branch (with less racy 'quota -f').
I removed everything related to recomputing from my patches (as well as 
quota.sets[]).

What is missing now is the new index field, which value will be used in 
mailbox_get_usage function. Since my changes do rely on this function, 
and sometimes computes a delta compared to a previous call of that 
function, it may not need to be updated afterwards ... I hope.
Then maybe some of the cassandane tests I pushed on our repository would 
need to be refreshed (at least the one that checks what happens for 
legacy mailboxes on which we add one of the newly handled quota resources).


Regards
Julien


More information about the Cyrus-devel mailing list