On Wed, Oct 28, 2020 at 09:52:07AM +0000, Arvin Schnell wrote:

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.

Unfortunately I found a situation where ignoring level 0 qgroups without a corresponding subvolume during probing leads to problems: The level 0 qgroup can be assigned to a higher level qgroup. If that higher level qgroup should be removed, all relations must be removed in advance. Without having the level 0 qgroup in the devicegraph also the relation is not known and thus the relation cannot be removed. And 'btrfs qgroup destroy' does not have a --force option. So I think all qgroups must be probed. But modifying level 0 qgroups without a corresponding subvolume is not supported. ciao Arvin -- Arvin Schnell, <aschnell@suse.com> Senior Software Engineer, Research & Development SUSE Software Solutions Germany GmbH Maxfeldstraße 5 90409 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

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: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org