Hi, 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. 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 -- 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