No subject

[Unknown]

berwaffe.com> <4ca38a03$0$923$415eb37d at crater_reader.dragonflybsd.org>
From: Chris Turner <c.turner at 199technologies.org>
Subject: Re: Thoughts on Quotas
Date: Wed, 29 Sep 2010 16:21:01 -0400
BestServHost: crater.dragonflybsd.org
List-Post: <mailto:kernel at crater.dragonflybsd.org>
List-Subscribe: <mailto:kernel-request at crater.dragonflybsd.org?body=subscribe>
List-Unsubscribe: <mailto:kernel-request at crater.dragonflybsd.org?body=unsubscribe>
List-Help: <mailto:kernel-request at crater.dragonflybsd.org?body=help>
List-Owner: <mailto:owner-kernel at crater.dragonflybsd.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4ca38a03$0$923$415eb37d at crater_reader.dragonflybsd.org>
Sender: kernel-errors at crater.dragonflybsd.org
Errors-To: kernel-errors at crater.dragonflybsd.org
Lines: 41
NNTP-Posting-Host: 216.240.41.25
X-Trace: 1285792038 crater_reader.dragonflybsd.org 924 216.240.41.25
Xref: crater_reader.dragonflybsd.org dragonfly.kernel:14606

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"

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.

- Chris