Bug 425040

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. ***