Re: Thoughts on Quotas
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.
討論串 (同標題文章)
完整討論串 (本文為第 22 之 32 篇)：