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
