[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>
From: Chris Turner <c.turner@199technologies.org>
Subject: Re: Thoughts on Quotas
Date: Tue, 28 Sep 2010 14:06:09 -0500
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: 7bit
In-Reply-To: <4ca21fbe$0$925$415eb37d@crater_reader.dragonflybsd.org>
Sender: kernel-errors@crater.dragonflybsd.org
Errors-To: kernel-errors@crater.dragonflybsd.org
Lines: 42
NNTP-Posting-Host: 216.240.41.25
X-Trace: 1285701696 crater_reader.dragonflybsd.org 923 216.240.41.25
Xref: crater_reader.dragonflybsd.org dragonfly.kernel:14594

Rumko wrote:
> 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.

could have responded to any number of subthreads but anyhow ..

this is true in some cases, but not all cases - the point about
the user not knowing (or needing/wanting to know) about the 'data change
rate', etc - is valid too.

certain sites wouldn't *want* the user deciding or being responsible for 
retention policy for a variety of technical, administrative and legal 
reasons

probably any given implementation should be flexible enough to allow
for a variety of scenarios -

e.g. system global retention / quota, user-level retention-quota,
various cleanup / warning policies to apply, etc.

no idea how feasable that would be with the current setup - but probably
the only kind of approach that would satisfy most use cases..

Anyone have any input about how other systems handle this - e.g. ZFS, 
LFS, various snapshot-capable SAN products, etc?

as for the # of users discussion - in these high-uid scenarios, you 
wouldn't typically share the same UID space - but have different ones -

e.g. on filesystem #1, the uid/gid info from systems a,b,c apply,
but on filesystem #2, the info from systems d,e,f apply - indeed
this is how people have been handling this problem on NFS setups for 
years - which is partly why there are things like dynamic NIS / LDAP 
maps, etc..

I'm sure a uid_t should support the needs of any one system for at least
a good while - and if system 1 is on PFS 1 - it's not a problem if the
administrator can configure PFS1 to have it's own retention policy, etc.