users can do funny things with btrfs qgroups leading to problems:
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.
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.
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.
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.
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.
Arvin Schnell, <aschnell(a)suse.com>
Senior Software Engineer, Research & Development
SUSE Software Solutions Germany GmbH
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org