Re: Thoughts on Quotas

[Rumko <rumcic@xxxxxxxxx>]

berwaffe.com> <4ca38a03$0$923$415eb37d@crater_reader.dragonflybsd.org> <20100929202101.GA6059@tao.199tech.net>
User-Agent: KNode/0.10.9
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
Lines: 58
NNTP-Posting-Host: 84.255.193.183
X-Trace: 1285793896 crater_reader.dragonflybsd.org 925 84.255.193.183
Xref: crater_reader.dragonflybsd.org dragonfly.kernel:14607

Chris Turner wrote:
> On Wed, Sep 29, 2010 at 08:48:35PM +0200, Rumko wrote:
>> 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.
> 
> This neglects the case where the user wants snapshots
> but doesn't want to track their historical use, etc.
> 
> Which I'd think would be a fairly common case -
> 
> applying it to traditional backups -
> how many shops have a backup policy that says:
> 
> "you can keep 10G of storage, and we make weekly full backups,
> and daily incrementals, but only if your daily incremental changes
> are < 40% of your total storage"
> 
> instead of:
> 
> "you can keep 10G of storage, and we make weekly full backups,
> and daily incrementals"

True, but in this case you forget that the current dataset and history are all
on the _same_ fs, so you can't just let the user run rampant on your hard
drives.

> Probably very few - and I'd think the same type of scenario
> would apply for hammer quota / retention specs..
> 
> Whatever is implemented needs to be flexible enough
> for the various scenarios of:
> 
>  - current user/system hard/soft quota (possibly 'group' as well)
>  - historical user/system hard/soft quota (possibly 'group' as well)
>  - user/group/admin managed retention & pruning
>    (in some capacity or the other - even if just
>     users being able to check usage / clean old snaps)
> 
> If theres a way to do that, unless I'm mistaken,
> most of the useful and varied possibilities are covered.

True, the main point I was trying to point, was that the user's historical data
has to be under quota as well ... if it's part of the user's total, or
separately defined as user's historical quota is besides the point and covered
by what you wrote above. And of course after reaching any of the quotas (for
current dataset, historical data or god forbid both) the user has to be
prohibited from writing.

> 
> - Chris
-- 
Please do not CC me, since I already receive everything from these MLs.

Regards,
Rumko