Re: Thoughts on Quotas

[Rumko <rumcic@xxxxxxxxx>]

4306bada0f913a31a8542a4@localhost> <AANLkTikvMCG8+CzpJdEM1OvvTzp6r7+jDgzzH_cWK5Ty@mail.gmail.com> <AANLkTinC62qdoVhr4=eV2fo2_NY4_VRs_X0gqgXJwR59@mail.gmail.com> <4ca21fbe$0$925$415eb37d@crater_reader.dragonflybsd.org> <AANLkTimffyU7UanW838=dRBg1Yd3PMaPsdxvByqx4Wmk@mail.gmail.com> <4ca34377$0$919$415eb37d@crater_reader.dragonflybsd.org> <4CA37D6B.4050309@yberwaffe.com>
User-Agent: KNode/0.10.9
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
Lines: 38
NNTP-Posting-Host: 84.255.193.183
X-Trace: 1285786115 crater_reader.dragonflybsd.org 923 84.255.193.183
Xref: crater_reader.dragonflybsd.org dragonfly.kernel:14604

Jasse Jansson wrote:
<snip>
> 
> 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.

Regards,
Rumko