Bug 2263965

it also *always* gives the subvolume the name "/", which seems a bit weird.

Btrfs suport in Cockpit is coming in pieces, but it is coming steadily and we are aware of its importance to the Installer, and the importance of the Installer to Fedora.

We can certainly do a better job of exposing our plans. They probably are somewhere in Jira.

I think you might be overlooking some features, such as the ability of creating multiple subvolumes. (Look for "Create subvolume" in the menu of a existing subvolume.) Other features, such as RAID and snapshots, are indeed missing. The UX in general is more clunky than it needs to be, and we have already started to streamline it, see for example https://github.com/cockpit-project/cockpit/issues/19920.

Any help is appreciated, of course.  Maybe you could do a little self-administered user test and record a quick screencast of how you try to create your desired btrfs storage layout and narrate how you struggle with this. That would be super valuable for us.

Thanks!

> I think you might be overlooking some features, such as the ability of creating multiple subvolumes. (Look for "Create subvolume" in the menu of a existing subvolume.)

I saw the option, but couldn't figure out how to use it. Trying again, though, I see; you have to "create a btrfs partition", then mount it (which in the installer environment seems to use an effective 'chroot' of /mnt/sysroot, though also see https://bugzilla.redhat.com/show_bug.cgi?id=2263971 ), then you can create a new subvolume (which is not visible at all on the screen you return to immediately after doing it, which is always confusing for the user).

I guess the experience was a little confusing at first because it's a very literal representation of how btrfs subvolumes work, which is somewhat confusing conceptually at first. Other UIs I've worked with try to fuzz the details a bit more to provide a more intuitive UX, but I guess it's a valid choice and will probably be appreciated by btrfs experts. Is the requirement to mount the first subvolume before creating others something enforced by btrfs itself?

Btrfs requires the file system mounted in order to create/remove subvolumes. The kernel code (and libbtrfsutil) can create/remove subvolumes by path or fd. The fd variant means the target subvolume does not need to be located in the mounted path. When using btrfs commands in a shell, we're generally limited to creating/removing subvolumes in a path available to the shell. An exception, we can delete subvolumes by subvolume ID, that subvolume does not need to be locatable in any mounted path, just the file system it exists on.

Reality is absurd, so I'm a fan of opinionated obfuscation of reality so long as it reduces absurdity. Easier said than done. :D Btrfs has very little opinion about subvolume layouts, so storage UI having an opinion is probably a good thing. But the consequences of opinions aren't so easy to imagine in advance, or work around later. So in the end it's just a bunch of tradeoffs like everything else.

> then you can create a new subvolume (which is not visible at all on the screen you return to immediately after doing it, which is always confusing for the user

That's a good point, and one we should fix with higher priority. You can create subvolumes right on the overview, and then they immediately appear in the overview of course, but when you go deep into the hierarchy all the way to the details page for a single subvolume, then you wont see new subvolumes that are created below it. The same is true for snapshots of logical volumes, for example.

So... with btrfs, Cockpit is a bit inconsistent: it shows a flat list of subvolumes, but the action for creating new ones treat it like a tree. Maybe we can show the subvolumes in a tree, or maybe we can have a single global "create" action. Or maybe we don't have pages for the individual subvolumes at all.  Hmm.

This is not a actionable bug report, sorry.