Thoughts on Quotas
rumcic at gmail.com
Wed Sep 29 11:48:35 PDT 2010
4306bada0f913a31a8542a4 at localhost> <AANLkTikvMCG8+CzpJdEM1OvvTzp6r7+jDgzzH_cWK5Ty at mail.gmail.com> <AANLkTinC62qdoVhr4=eV2fo2_NY4_VRs_X0gqgXJwR59 at mail.gmail.com> <4ca21fbe$0$925$415eb37d at crater_reader.dragonflybsd.org> <AANLkTimffyU7UanW838=dRBg1Yd3PMaPsdxvByqx4Wmk at mail.gmail.com> <4ca34377$0$919$415eb37d at crater_reader.dragonflybsd.org> <4CA37D6B.4050309 at yberwaffe.com>
Content-Type: text/plain; charset=us-ascii
X-Trace: 1285786115 crater_reader.dragonflybsd.org 923 18.104.22.168
Xref: crater_reader.dragonflybsd.org dragonfly.kernel:14604
Jasse Jansson wrote:
> While you're at it, why don't make two kinds of snapshots.
> 1. A user initiated snapshot, usnap, that the user controls and counts
> towards the quota limit.
These already exist? They are called backups ... rsync, cpdup, cp, bacula,
amanda, etc. already do this and as the source you can provide them with any
snapshot that you have access to or even the current dataset if you don't care
if it's changing while you're copying it.
It might be nice from certain perspectives (though, I'd disagree) but in any
case, this is off-topic, we were supposed to be discussing user/pfs quotas
with current HAMMER fs and in this case, even though the user only has
indirect control over snapshots (asking the admin to manage them and by
limiting rewrites of files), quotas are supposed to limit the user's impact on
disk space ... if historical data is not accounted for, there is in fact no
limit on the user's impact on disk space (e.g. you give the user a hard quota
of 1GB ... the user will take a 1TB file, split it into 1GB sized parts and
start saving it over and over itself ... the user will still be able to access
most/all those parts from file's history, but will only pay the price of the
last piece or in an even worse scenario, will fill up your drive and the other
nicer users wont be able to use your services).
And like I said before ... the users home dir can be nohistory and the user
won't have to worry about his snapshots taking space up.
If the user wants transparent history and snapshots which are made
automatically in the bg, then the user has to pay the price. If the user
doesn't care about that, then his dir can be nohistory and then the quota
system can only count the current dataset, since there is no historical data
for that user.
Please do not CC me, since I already receive everything from these MLs.
More information about the Kernel