MESSAGE quota resource implemention
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
> 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
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).
More information about the Cyrus-devel