MESSAGE quota resource implemention
julien.coloos at atos.net
Thu Sep 1 11:13:38 EDT 2011
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)
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.
> 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
> 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!
More information about the Cyrus-devel