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
