MESSAGE quota resource implemention

Bron Gondwana brong at fastmail.fm
Mon Sep 12 17:09:13 EDT 2011


On Mon, Sep 12, 2011 at 04:46:52PM +0200, Julien Coloos wrote:
> Le 09/09/2011 14:18, Greg Banks a écrit :
> >Ok, here you go. Not completely tested yet, so caveat emptor.
> Remaining things concerning annotations:
>  - when deleting messages, annotations length is not substracted;
> the solution may not be that simple, since I believe users are
> allowed to unexpunge mails: so since index entry is still here -
> until real unlinking -, annotations may have to stay there too -
> until unlinking too

When they unexpunge, you add it back.  The decision to have
delayed expunge and WHEN to expunge is a server administrator
decision that's outside the control of the user.

With storage, we subtract the usage when we mark the record
expunged.  Annotation length should be handled the same way.
This will have to be done when the message gets expunged,
by finding the size of the annotations and subtracting that
also.

>  - for 'old' mailboxes (those created before the annotation storage
> usage field in the index header), current annotations usage shall be
> computed (and added to the quota entry) upon upgrading; this way
> users won't have to run 'quota -f' for all quotaroots after
> switching to this new version ;)

Definitely.  Upgrading usually handles things like that.  It's
the right way[tm].

> Actually I just gave up the 'old' test: there is no easy way to
> simulate upgrading mailbox index, or at least I don't feel confident
> enough to make it in cassandane :(

Easiest way is the same way I did for the broken quotas test.
Have a tar file with the contents of the "old mailbox" which
you unpack onto the filesystem, and then open the mailbox and
check that the "upgraded" fields are what you would expect.

I also did something similar for the "crash on thread" test,
where there were 5 messages which were known to be able to
crash the THREAD command.  I unpacked the folder contents
with those messages in a test.

Regards,

Bron.


More information about the Cyrus-devel mailing list