how to deal with quotas / suggested feature "monthly quota increase"
gavin.mccullagh at gcd.ie
Fri Aug 27 12:12:48 CEST 2010
I've been mulling over how we deal with quotas for a while now. We haven't
really been too rigorous with them up to now, but I'd like to change that.
At the same time, I'd like to reduce the workload associated with
I've graphed our imap spool disk usage in the past and found that it is a
moreorless linear increase (perhaps slightly super-linear due perhaps to
new staff hiring, more/larger email usage etc). This makes sense, even the
most frugal users accumulate new mail each month. Their own behaviour in
deleting mail may change the slope of the line, but it will still increase
If that is the case, having a static quota is futile. Every user will some
day exceed their quota and there's no shame in it. Our staff who take the
call can't easily tell if that user has been careful or not so everyone has
the same discussion which ultimately results in an increased quota. The
magnitude of the existing quota is all they have to go on, but that takes
no account of how long the staff member has been accumulating mail.
I propose to introduce a simple linear quota increase scheme in our
organisation. A new user starts with a standard quota of C. Then, each
fixed period (probably month), we increase the quota by a standard amount
Q(t) = M*t + C
Now people have a budget each month which they should try and stick to. If
they exceed their quota, it's because they're not sticking to their budget
and we can have a discussion about that. If we set a reasonable value for
the global M, we should hopefully get far less people exceeding their
quota. For some heavy users, we can agree a larger value for M. It might
be necessary every year or two to increase the M for all users.
I can script this up myself but it would be fantastic if it could be
implemented in Kolab (something I'm happy to help with). As far as I can
see, you'd just need a single extra user entry in the LDAP database to
describe the M, "Quota Increase Per Month" and a default value for that (so
if left blank, th global default M value applies). Then a monthly cron job
could look after the increase.
There might be an argument for further tuning M (eg if in a given month, a
user's disk usage is not within M of their quota, we don't increase it that
month). This would avoid idle accounts from ending up with massive quotas.
This also gives an administrator a means to plan for future disk usage.
You can sum M for every user and you have the projected monthly increase in
disk usage per month.
Kolab users who don't want this feature, simply leave M=0, which would be
Does this sounds useful, ridiculous, pointless, flawed, something else?
More information about the users