[no subject]

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>
From: Jasse Jansson <jasse@yberwaffe.com>
Subject: Re: Thoughts on Quotas
Date: Wed, 29 Sep 2010 19:54:51 +0200
BestServHost: crater.dragonflybsd.org
List-Post: <mailto:kernel@crater.dragonflybsd.org>
List-Subscribe: <mailto:kernel-request@crater.dragonflybsd.org?body=subscribe>
List-Unsubscribe: <mailto:kernel-request@crater.dragonflybsd.org?body=unsubscribe>
List-Help: <mailto:kernel-request@crater.dragonflybsd.org?body=help>
List-Owner: <mailto:owner-kernel@crater.dragonflybsd.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
In-Reply-To: <4ca34377$0$919$415eb37d@crater_reader.dragonflybsd.org>
Sender: kernel-errors@crater.dragonflybsd.org
Errors-To: kernel-errors@crater.dragonflybsd.org
Lines: 62
NNTP-Posting-Host: 216.240.41.25
X-Trace: 1285783772 crater_reader.dragonflybsd.org 925 216.240.41.25
Xref: crater_reader.dragonflybsd.org dragonfly.kernel:14603

  On 09/29/10 03:47 PM, Rumko wrote:
> Stathis Kamperis wrote:
>
>> 2010/9/28 Rumko<rumcic@gmail.com>:
>>> Stathis Kamperis wrote:
>>>
>>>> 2010/9/28 Sdävtaker<sdavtaker@gmail.com>:
>>>>> What i tried to sai about history was that user usage should be
>>>>> measured in a different bag than the history that the user usage
>>>>> generated.
>>>>> Sorry if it was not clear, english is not my main language and i use
>>>>> to fail time to time. :-/
>>>>> Damian
>>>>>
>>>> I kind of agree.
>>>>
>>>> Why "punish" user for something that s/he is not able to control
>>>> directly ? Even more, the user may not be aware of the underlying
>>>> filesystem's technicalities (how it retains history and so on).
>>>>
>>>> Better come up with something else.
>>>>
>>>> Best regards,
>>>> Stathis
>>> Not punishing that user means punishing the whole system and everything
>>> depending on that system. And as I said before, it's user's data, so who
>>> should be punished if not the user? The user can always tell the admin that
>>> he does not any history at all or how much history he needs, so it's purely
>>> that user's responsibility ... his data, his rules, his reponsibility.
>>> [...]
>> Ok, fine. I'm not strongly opinionated on this. I'm just thinking from
>> the Josephine perspective, who may not (or even want to) know how her
>> file-system operates.
> Then that user's home dir can be nohistory and there is no problem?
> If she doesn't need multiple copies of her data, then I see no reason why to
> keep that data. But if she wants n snapshots/backups then there should be a
> limit on how much total space she can take. Otherwise we could just display
> du -h of her home dir when she logs in and it would be about as useful at
> limiting her disk usage, so there would be no point to a quota ;)
> On purpose she could bring down the whole system at will even though she
> was "limited", but unfortunately she could do it unknowingly as well
> (downloading flash videos, powerpoint jokes, maybe a movie or two, etc. over
> and over and rewriting the old files).
>
>> But if we go this route, then we should also provide history retention
>> statistics to user-land utilities, such as df(1).
>>
>> Imagine the confusion of a user that types 'df', sees that the quota
>> threshold hasn't been reached, yet she is denied further disk storage
>> allocation.
> Agreed, now we just need to find someone to do it :P

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.

2. System snapshots, ssnap, obviously managed by the system/admin (out 
of control of the user) and therefore counts as system overhead.