MESSAGE quota resource implemention

[Bron Gondwana]

On Wed, Aug 31, 2011 at 05:50:36PM +0200, Julien Coloos wrote:
> Things that may be worth noting:
>   - DUMP/UNDUMP currently does nothing special about MESSAGE or
> X-ANNOTATION-STORAGE quota resources
>     -> should it be transferred ?

I'd like to replace DUMP/UNDUMP with replication protocol
communications for XFER.

>     -> without breaking backward compatibility, limits could only be
> transferred through a 'fake' file entry, as for annotations

But for now, that's definitely the pragmatic way to go.

>   - quota usage is currently stored in a uquota_t variable, and
> delta is computed as quota_t; so theorically there could be overflow
> issues if quota usage to add/substract cannot be held in a quota_t;
> in practice it should be unlikely since that would mean a usage of
> over 2^63-1

I propose we scrap uquota_t - it is un-necessary for the medium-term
future, now that we're requiring 64 bit types.

> I think that there are two things that may also be done concerning
> quota entries:
>   - always recompute resource usage when changing its limit from
> unlimited to bounded

That's not too expensive really - we do it in the "quota" tool anyway.

The bigger issue is locking.  You need to be very careful of deadlock
situations if you do this.  We have that issue in the quota tool now.

The only _real_ way to do it reliably would be to go through and
remove all the quota roots from each mailbox, then go through again
one at a time and add them back, recording usage as you go.  Otherwise
there's no way of knowing if your end result is consistent.

>     -> that way, it may not be necessary to track resource presence
> when reading/writing quota entries
>     -> but maybe it could be too time consuming in some cases, since
> it seems to be possible to associate a quota resource to a whole
> domain (recomputing usage for all mailboxes would then take some
> time)

Yeah, now this is what you could call all sorts of bad names.  It's
really not sane to keep a quota counter at EVERY possible level in
the tree just incase someone wants to hang a limit there later.
You would get insane amounts of contention on the domain quota
lock for a busy domain, which would be un-necessary.

> PS: should I open a new bugzilla ticket for that ?

Why not - numbers are cheap.

> PPS:
> cunit: on my computer cunit tests succeed except the 'foreach' one
> in the 'quota' suite which timeouts (it seems messing with 4096
> quotalegacy is too much for my computer).

There's stuff you can do with fd limits.  Check out /etc/pam.d/* for
pam_limits.so, and then /etc/security/limits.conf.  I just had to
learn about that stuff today!

Bron.