Re: Thoughts on Quotas

看板DFBSD_kernel作者時間15年前 (2010/09/30 04:32), 編輯推噓0(000)
留言0則, 0人參與, 最新討論串30/32 (看更多)
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
文章代碼(AID): #1Cew95eh (DFBSD_kernel)
討論串 (同標題文章)
文章代碼(AID): #1Cew95eh (DFBSD_kernel)