ZFS user/group quotas & space accounting [PSARC/2009/204 FastTrack timeout 04/08/2009]

[Matthew Ahrens]

Darren Reed wrote:
> Matthew Ahrens wrote:
>> ...
>> User space accounting and quotas "stick with" each dataset (snapshot,
>> filesystem, and clone).  This means that user quotas (and space
>> accounting) are not inherited.  They will be "copied" to a new snapshot,
>> and keep the values they had at the time the snapshot was taken.
>> Likewise, user quotas will be "copied" to a clone (from its origin
>> snapshot), and they will be copied with "zfs send" (even without -R).
>> (User accounting and quota information is not actually copied to
>> snapshots and clones, just referenced and copied-on-write like other
>> filesystem contents.)
> 
> If I read this right then the implication is that a user can use
> snapshot/clone to increase their allotted quota in a givern pool
> because they can create more datasets with their own quota, correct?

Yes, if you have permission to create clones, you can make more space 
available to yourself.  I doubt sysadmins will do this in practice (setting a 
quota on someone with sysadmin privs).

> So if I start out with tank/test1 that has a quota of 2GB, create a
> snapshot of that (tank/test1 at now) and then clone it (test/test1_clone),
> I end up with 4GB of quota for tank/test1. That's different.

No.  If you do:

zfs create pool/fs
zfs set userquota at dreed=2G pool/fs
zfs snapshot pool/fs at snap
zfs clone pool/fs at snap pool/clone

then user dreed is now allowed to use 2G in pool/fs and 2G in pool/clone. 
The quota on pool/fs is not changed.

> If at some point in the future there was a desire to implement quotas
> for pools, does anything this project delivers make that "impossible"?

No, it makes it easier.  (And yes, there are pitfalls with zones; let's save 
this discussion for a later date.)

--matt