DragonFly kernel List (threaded) for 2010-09
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 <firstname.lastname@example.org>
Subject: Re: Thoughts on Quotas
Date: Tue, 28 Sep 2010 14:06:09 -0500
Content-Type: text/plain; charset=utf-8; format=flowed
X-Trace: 1285701696 crater_reader.dragonflybsd.org 923 18.104.22.168
Xref: crater_reader.dragonflybsd.org dragonfly.kernel:14594
> 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
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
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.