MESSAGE quota resource implemention

Greg Banks gnb at fastmail.fm
Mon Sep 5 06:20:08 EDT 2011


On 05/09/11 20:06, Bron Gondwana wrote:
> On Mon, Sep 05, 2011 at 02:32:40PM +1000, Greg Banks wrote:
>> Ok, I'm now convinced my first attempt at annotation quotas sucked too
>> hard, here's how I want to re-implement it.  Let me know what you think.
> 
>>  - 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,

Do we even have a db backend that would support that?

> 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.
> 
>>  - at header upgrade time, write the special value ~0 into this field,
>> meaning "unknown"
> 
> Funky.  If you didn't want to get all special-value about it, you could
> use a flag over in the flags field as well, there are only about 5 of
> the 32 in use so far.

Sure.

>>  - in mailbox_commit_quota(), if the field is not "unknown", then
>> calculate the delta in usage and apply to the quota db.
> 
> I assume this is done the same way it's done now?

Something like that.

>  By taking a "snapshot"
> of the value at the start, and calculating a diff to apply at the end.
> That was actually a filthy workaround (one of many, dammit) for using
> unsigned datatypes.  If we made this a signed 64 bit datatype as well,
> with a flag off to the side for "unknown", then we could actually store
> a diff in the mailbox object directly - and update both this field and
> the quota's value during the commit.

Ok.

>>  - make reconstruct scan the annotations db to figure out the correct
>> value for this new field.
> 
> Yep - that makes sense.  Reconstruct already does this for the
> quota_mailbox_used field, doesn't it.

Yes.

>  And any other derived
> "aggregate" values in the header.
> 
>> This means that the annotation STORE and SETMETADATA paths will be
>> updating the quota db in the same place that APPEND et al do,
>> mailbox_commit_quota().  This should work around Bug #3529 and also make
>> the code neater.
> 
> Nice.

Yeah, all I have to do is work out how to futz with the annotate API yet
again :(


-- 
Greg.


More information about the Cyrus-devel mailing list