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.
