On 10/28/20 10:52 AM, Arvin Schnell wrote: > > Hi, > > users can do funny things with btrfs qgroups leading to problems:
Indeed. That's why the YaST plan is to allow very limited management of quotas, not even exposing the concept of qgroups to the user. > When a subvolume is created a corresponding level 0 qgroup is > also created by btrfs. The subvolume id and thus the qgroup id > are not predictable (see below). The user can also manually > create level 0 qgroups. I guess YaST itself may need to create level 0 qgroups in some situations (eg. enabling quotas for the first time for an already existing filesystem). But that's a possibility we do NOT plan to offer to the user of (Auto)YaST. > So the user can 1) manually create qgroup 0/260 and 2) create a > subvolume that could get id 260 and the corresponding qgroup gets > the id 0/260. A nice qgroup id collision. > > If libstorage-ng would commit such a setup the manually creation > of qgroup 0/260 would fail if it happens after the subvolume > creation. Also the user could set different limits for both > qgroups which is obviously impossible to commit correctly. > > I do not see any use-case for level 0 qgroups without a > corresponding subvolume. Our btrfs developers also said that > there is none. Indeed I don't see a use-case for that. Moreover, the only use-case we want to cover with YaST quotas support is setting a limit in a subvolume to avoid its excessive growth. In a similar way that it can be done by using a separate partition or a separate LVM volume. Nothing else. That's why we will not expose the concept of qgroups, the user will just set the limits for each subvolume. Under the hood that would be setting the limit in the associated qgroup, but that should be a hidden implementation detail. > So to avoid such problems with libstorage-ng and YaST I propose > to 1) disallow creating level 0 qgroups without an corresponding > subvolume and 2) ignore level 0 qgroups without a corresponding > subvolume during probing. Fine for YaST. As explained in Jira[1] and other places, YaST plans to completely ignore all qgroups except the ones directly associated to each subvolume. > Item 2) seems like a good idea anyway since btrfs does not delete > qgroups when deleting subvolumes, so a hugh number (like several > thousands) of useless level 0 qgroups may exist in the system. Unless we change our minds, the plan is that YaST will delete those qgroups when deleting the corresponding subvolume. > Comments? > > Why is the subvolume id not predictable? For once it is not just > the next free id: E.g. after deleting all subvolume the ids do > not restart at 257. Likely it is possible by further analysis of > the btrfs to know the next id but that is internal to btrfs. And > finally any other program, e.g. snapper, can concurrently create > subvolumes and thus ruin any attempt to predict the ids. > > ciao > Arvin Cheers. [1] https://jira.suse.com/browse/SLE-15283?focusedCommentId=1021230&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-1021230 -- Ancor González Sosa YaST Team at SUSE Software Solutions -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
