Thoughts on Quotas

Rumko rumcic at
Tue Sep 28 07:33:36 PDT 2010

Sdävtaker wrote:
> I think historical data should not affect user quota since user is
> unable to clean up his own historical data.
> Historical data should be seen as administrative overhead, there is a
> need to know some metric about the historical data so cleanup can be
> automatized to avoid the scenario where users "got" space but it
> doesnt exist phisically in the box.
> Damian
> On Tue, Sep 28, 2010 at 06:25, Antonio Huete Jimenez
> <ahuete.devel at> wrote:
>> One of my concerns here is, as the historical data is taking up more
>> and more disk space without being taken in account, it could be the
>> case that there's not enough space to satifisfy user's disk needs even
>> if they're not reaching the quotas.
>> How would that case be handled? Should the sysadmin take this in account?
>> I'm not 100% sure that the historical data shouldn't count on the total sum.
>> Cheers,
>> Antonio Huete

My 2 cents ...
With regards to having historical data included in the quota system. IMHO, it
should be included ... the user itself might not be able to affect that
variable directly, but it's still his data that is taking up the space (e.g.
when you have managed hosting somewhere and also sign up for automated
backups, even though they are just backups, you still have to pay for how much
space your backups take ;) ) ...
If I were to set up a PFS/dir for a specific user and he'd ask for per hourly
snaps for the last 5 years, he can have them if he wants, as long as the
combined usage of snaps + current data is not more than what I am willing to
dedicate to that user (e.g. 1GB).
At the least, the user could create a DoS attack on the complete system by
rewriting his files over and over and over, until he would've taken all of the
available disk space (and none of the other users could use their space due to
that), even though he had a hard quota set to (e.g.) 10MB.

More information about the Kernel mailing list