MESSAGE quota resource implemention

[Julien Coloos]

Le 01/09/2011 14:22, Bron Gondwana a écrit :
>
> A provisioning system could run quota -f itself after making the
> change, of course.
Sure. But since the quota is being changed, clients would wonder why 
they need to call another quota utility to finish the job.
Plus I wanted to have something similar to how it works when the quota 
entry is first created (which previously only managed one resource): 
people didn't need to call the quota utility after creating the 
quotaroot, so if it's doable for other resources it's better.

>> But I agree that in case of underflow detection throwing a warning
>> in syslog might help draw the attention when logs are analysed.
> "when".  haha.
>
> (maybe at a few sites that care... but for the vast majority of
>   sites, if you're depending on them reading syslog you've already
>   lost.  Software that understands that and is robust in the face
>   of errors is much nicer for the poor suckers on the receiving end
>   of all this)
>
:D
It's sometimes hard to find a good compromise between "we have good 
faith current data are correct, so for non-vital ones we perform minimal 
checks and provide tools to repair punctually" and "we are paranoid and 
check/repair each and every data all the time" ;)
But I am a bit biased here due to past experiences with non-robust/buggy 
code that tries to correct itself and often ends up in endless iterations...

>
> FYI - I'm planning to be a bit more lazy about mailbox deletes
> at some point.  It would be super-cool to not even move the files
> until someone trys to create a new mailbox with the same name,
> otherwise just clean them up in the regular course of cyr_expire.
>
> Need to think about that some more though.

> Actually, really I'd like to create a new UNIQUEID - and store
> all the files in paths based on uniqueid rather than on folder
> name.  This would not only mean renames could be fast and
> atomic, but that delayed delete would be fast.  The downside is
> a more opaque filesystem layout.  Oh, another upside - file path
> limitations don't exist so much any more.
Nice :)

>
> One place please :)  Ideally I'd like to absorb more of the quota
> stuff into mailbox.c.  Greg and I have some debate about this - how
> much is too much for that file to be doing.  Probably it should be
> abstracted into a couple of layers of stuff - but I really do like
> the consistency of having just a couple of function calls:
>
> mailbox_append_index_record; and
> mailbox_update_index_record
>
> which do all the consistency checking and counter updating inside.
> Plus of course a mailbox_check_quota thing that takes a set of
> quota checks to do and sees if there will be space for the
> planned changes!
Makes sense.


Regards
Julien