On 10/28/20 10:52 AM, Arvin Schnell wrote:
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
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)
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
So to avoid such problems with libstorage-ng and YaST
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 and other places, YaST plans to
completely ignore all qgroups except the ones directly associated to
Item 2) seems like a good idea anyway since btrfs does
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.
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.
Ancor González Sosa
YaST Team at SUSE Software Solutions
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org