I''m seeing some unexpected and strange behaviour with respect to quotas and zones. Initially I set things up with no quota on the data set that as delegated to the zone. Then as the local zone admin I created a new child dataset and set a quota on that. Now the global zone admin attempts to quota the delegated dataset, and it appears to work but.... global zone=pingpong local zone=player2 delated dataset is table/player2 pingpong:pts/1# zfs get quota table/player2 NAME PROPERTY VALUE SOURCE table/player2 quota none default pingpong:pts/1# zlogin player2 [Connected to zone ''player2'' pts/2] Last login: Wed Apr 12 06:53:47 on pts/2 Sun Microsystems Inc. SunOS 5.11 snv_37 October 2007 # zfs get quota table/player2 NAME PROPERTY VALUE SOURCE table/player2 quota none default # zfs set quota=20g table/player2 cannot set quota for ''table/player2'': permission denied As expected but... # zfs create table/player2/round1 # zfs set quota=20g table/player2/round1 # ^D [Connection to zone ''player2'' pts/2 closed] pingpong:pts/1# zfs get quota table/player2/round1 NAME PROPERTY VALUE SOURCE table/player2/round1 quota 20G local Okay so we can see what the local zone admin did. Time to clamp down on the usage by zone player2 pingpong:pts/1# zfs set quota=10g table/player2 pingpong:pts/1# zfs get quota table/player2/round1 NAME PROPERTY VALUE SOURCE table/player2/round1 quota 20G local Hmn so the dataset that the local zone admin created has a higher quota than the one that contains it. Thats strange and not what I wanted. pingpong:pts/1# zlogin player2 [Connected to zone ''player2'' pts/2] Last login: Wed Apr 12 06:54:34 on pts/2 Sun Microsystems Inc. SunOS 5.11 snv_37 October 2007 # zfs get -r quota table/player2 NAME PROPERTY VALUE SOURCE table/player2 quota 10G local table/player2/round1 quota 20G local Yep looks the same from inside the zone too. What am I missing here, is this a known issue ? -- Darren J Moffat
On Tue, Apr 25, 2006 at 12:49:37PM +0100, Darren J Moffat wrote:> # zfs set quota=20g table/player2/round1 > pingpong:pts/1# zfs set quota=10g table/player2 > pingpong:pts/1# zfs get quota table/player2/round1 > NAME PROPERTY VALUE SOURCE > table/player2/round1 quota 20G local > > Hmn so the dataset that the local zone admin created has a higher > quota than the one that contains it. Thats strange and not what I > wanted.FYI, this behavior is the same even with no zones involved. Quotas apply to the filesystem they are applied to and all descendents. What behavior did you want? Did you want the ''zfs set quota=10g table/player2'' to fail? I don''t think it should -- you are setting a smaller limit, but that limit does not inherently interact with the larger limit. Perhaps we could issue an informative message reminding you that the larger quota can never be enforced since you''ve put in a smaller quota above it. Maybe an analogy would help explain this situation. Let''s say that your state government imposes a quota on how many people are allowed to live in a certain city: ca-legislature# zfs set quota=100m gov/usa/california/sanfrancisco The federal government could then set a quota on how many people can live in that state, and that quota could be smaller than the previous quota: usa-legislature# zfs set quota=50m gov/usa/california Both of these are valid quotas (assuming that the laws are actually legal), but the one on sanfrancisco is moot as long as there is a smaller quota on california as a whole. I agree that it is a little confusing to have a larger quota inside a smaller quota. The larger quota will never take effect. However, remember that quotas are limits, not reservations. Now if you had set a 20gb reservation on table/player2/round1, you would not be able to set a 10gb quota on table/player2, because it''s already "using" more than that. --matt
Matthew Ahrens wrote:> On Tue, Apr 25, 2006 at 12:49:37PM +0100, Darren J Moffat wrote: >> # zfs set quota=20g table/player2/round1 >> pingpong:pts/1# zfs set quota=10g table/player2 >> pingpong:pts/1# zfs get quota table/player2/round1 >> NAME PROPERTY VALUE SOURCE >> table/player2/round1 quota 20G local >> >> Hmn so the dataset that the local zone admin created has a higher >> quota than the one that contains it. Thats strange and not what I >> wanted. > > FYI, this behavior is the same even with no zones involved. Quotas > apply to the filesystem they are applied to and all descendents.I see the Zones case a little different to the normal nested dataset case because with a data set delegated to a zone you see things a little differently, my case was simple but the quota could have been set a couple of data sets "above" the one delegated to the zone. Looking forward to when data sets can be delegated to users I want to be able to ensure that I can set a top level quota on a delegated user file system (say their home dir) and have it apply to all data sets they create below that. I want to be able to do this at any time. I think what you are saying is that this works but it isn''t what zfs(1) lets you see, right ? You are syaing that the 10g quota would have been enforced even though table/player2/round1 has a 20g quota.> What behavior did you want? Did you want the ''zfs set quota=10gGiven that the quota had not been reached yet what I really wanted was at least a warning in the global zone saying that I was adjusting the quota of a delegated data set that also had quotas set and there was a mismatch,. Really I was expecting for the value returned by zfs get on the nested data set in the zone to now return 10g rather than 20g. This is an observability problem. -- Darren J Moffat
On Wed, Apr 26, 2006 at 09:38:05AM +0100, Darren J Moffat wrote:> Looking forward to when data sets can be delegated to users I want to be > able to ensure that I can set a top level quota on a delegated user file > system (say their home dir) and have it apply to all data sets they > create below that. I want to be able to do this at any time.Yep, this is always the case. Quotas always apply to the space used by all descendent filesystems.> I think what you are saying is that this works but it isn''t what zfs(1) > lets you see, right ? You are syaing that the 10g quota would have been > enforced even though table/player2/round1 has a 20g quota.Yes, you can not violate any quota, regardless of any other quotas. I believe that zfs(1m) displays the correct thing. The ''quota'' property is always the quota that has been administratively set on *that* filesystem. The quota property is not inherited, but affects its descendents by (potentially) changing their available space. So in your example, table/player2/round1 will show at most 10g available (but possibly less, as its siblings (eg. table/player2/round2) could use up some of the quota on table/player2).> >What behavior did you want? Did you want the ''zfs set quota=10g > > Given that the quota had not been reached yet what I really wanted was > at least a warning in the global zone saying that I was adjusting the > quota of a delegated data set that also had quotas set and there was a > mismatch,.I agree that an informative message might be nice, along the lines of "FYI, there is a larger quotas set on this descendent filesystems, which are will not be useful as long as this quota is in place."> Really I was expecting for the value returned by zfs get on the nested > data set in the zone to now return 10g rather than 20g.I don''t think that we should go lowering the descendent''s quotas. I think that would be quite surprising to the zone admin, especially if the higher-level quota is eventually increased. I suppose we could introduce a "lowest quota applied here" but I think it would be more useful to generalize it to "maximum amount of space that this fs can use" (taking into account parent''s quota that''s been used by siblings, reservations elsewhere in the pool, and total storage), which is simply used + available.> This is an observability problem.Not in my mind, as the space available will reflect the new quota. --matt