Created attachment 130661 [details] KDE Partition Manager showing incomplete representation of Btrfs volume SUMMARY When using Btrfs, KDE Partition Manager does not represent subvolumes in any way, leading to an incomplete description of the disk setup. STEPS TO REPRODUCE 1. Install Fedora KDE with Btrfs through Custom partitioning 2. Open KDE Partition Manager OBSERVED RESULT KDE Partition Manager shows the Btrfs volume with only the / subvolume mountpoint described. EXPECTED RESULT KDE Partition Manager shows the Btrfs volume with all subvolume mountpoints described. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora 32 (available in About System) KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.70.0 Qt Version: 5.14.2 ADDITIONAL INFORMATION
Note, this is the layout my system has, according to 'df': [ngompa@Belldandy-Slimbook ~]$ df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 3.8G 0 3.8G 0% /dev tmpfs 3.9G 471M 3.4G 13% /dev/shm tmpfs 3.9G 1.6M 3.9G 1% /run /dev/nvme0n1p4 224G 7.3G 216G 4% / tmpfs 3.9G 1.4M 3.9G 1% /tmp /dev/nvme0n1p4 224G 7.3G 216G 4% /home /dev/nvme0n1p2 976M 249M 660M 28% /boot /dev/nvme0n1p1 599M 21M 579M 4% /boot/efi tmpfs 782M 0 782M 0% /run/user/989 tmpfs 782M 56K 782M 1% /run/user/1000
Yeah, that's true. It's something I would like to improve (since I use btrfs subvolumes myself), just didn't find time yet.
For context, I started digging into this because Fedora is switching to Btrfs by default[1] for Fedora 33. [1]: https://fedoraproject.org/wiki/Changes/BtrfsByDefault
(In reply to Neal Gompa from comment #3) > For context, I started digging into this because Fedora is switching to > Btrfs by default[1] for Fedora 33. > > [1]: https://fedoraproject.org/wiki/Changes/BtrfsByDefault Yeah, I've heard that too. Well, btrfs is getting more stable, so that's not unexpected. It was definitely more unstable 10 years ago when I switched to it. In any case, I don't think this can be ready for the next release (next release will probably come out this autumn) unless somebody contributes some patches but it's not entirely trivial to implement. This is file system specific feature, so some way of dealing with that should be added to kpmcore library and GUI needs to be taught how to display it. Speaking of that, what do you think would be best representation of btrfs subvolumes in GUI? It's not really the whole partition, they don't have an allocated space.
(In reply to Andrius Štikonas from comment #4) > (In reply to Neal Gompa from comment #3) > > For context, I started digging into this because Fedora is switching to > > Btrfs by default[1] for Fedora 33. > > > > [1]: https://fedoraproject.org/wiki/Changes/BtrfsByDefault > > Yeah, I've heard that too. Well, btrfs is getting more stable, so that's not > unexpected. It was definitely more unstable 10 years ago when I switched to > it. > I switched five years ago myself. It's become quite awesome in a very short time. :) > In any case, I don't think this can be ready for the next release (next > release will probably come out this autumn) unless somebody contributes some > patches but it's not entirely trivial to implement. This is file system > specific feature, so some way of dealing with that should be added to > kpmcore library and GUI needs to be taught how to display it. > > Speaking of that, what do you think would be best representation of btrfs > subvolumes in GUI? It's not really the whole partition, they don't have an > allocated space. If the subvolumes aren't associated with a quota of some kind, I think just showing them as a list of mountpoints is fine. If a subvolume has a quota to impose size limits, then I think we'd need to talk about how to represent "inner partitions" within the Btrfs volume. Subvolumes have names, so the mountpoint would have to be mapped to that. When quotas exist, the "inner partitions" would be named by the subvolume name, mapped to their mount point.
(In reply to Neal Gompa from comment #5) > If the subvolumes aren't associated with a quota of some kind, I think just > showing them as a list of mountpoints is fine. If a subvolume has a quota to > impose size limits, then I think we'd need to talk about how to represent > "inner partitions" within the Btrfs volume. Subvolumes have names, so the > mountpoint would have to be mapped to that. When quotas exist, the "inner > partitions" would be named by the subvolume name, mapped to their mount > point. I thought about this a little, mountpoints and subvolumes are slightly different, one subvolume can be mounted in a few places or not mounted at all.
Perhaps limit partition manager to subvolumes in a flat layout in the top-level of the file system, i.e. only list, create, delete, and assign top-level subvolumes. They could be assigned to arbitrary mountpoints. And maybe limit the file manager to subvolumes in the nested layout, where it's a special kind of directory? https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Layout Btrfs supports 2^64 subvolumes. It could be that there will be many client/owners of subvolumes that expect exclusive access, e.g. snapper, podman/mobi, timeshift, btrbk, etc. Partition manager may not want to be in a position of having to manage everything, or in some sense make it easy for users to inadvertently mess up some other application's realm. Instead it might care more about the multiple device handling of Btrfs, add/remove/replace devices. Maybe in the short term we should just ideate, and look at what libbtrfsutil, libblockdev, and udisks2 need. There is: http://storaged.org/doc/udisks2-api/latest/gdbus-org.freedesktop.UDisks2.Filesystem.BTRFS.html Does it make sense to include some kind of list limiting or filtering within this library? Or expect every client to handle possibly thousands of items in a GetSubvolumes method?
*** Bug 490904 has been marked as a duplicate of this bug. ***