Designing the Btrfs management UI for Agama

[ancorgs]

The general approach for presenting the storage options to the Agama users is discussed at storage_ui.md and summarized by this mock-up extracted from that document.

But choosing Btrfs for the root file-system opens many possibilities and can even change the way the devices are organized. For example, using subvolumes instead of separate file-systems or spreading the Btrfs over several block devices (using Btrfs RAID).

Btrfs implications

In YaST, Btrfs is just another file-system type that can be chosen (like ext4 or xfs). But it actually has many implications like:

• Btrfs is forced in case of transactional systems
• Possibility to enable snapshots (with the corresponding impact in the suggested sizes for the underlying block device)
• Subvolumes (including shadowing)
• Possibility to define subvolume quotas
• Multi-device file-systems (RAID)

All that happens because Btrfs goes conceptually beyond the traditional Linux file-systems. It simply works in a different way at several levels.

Solutions

The goal of this discussion is to agree on reasonable solutions to represent the relevant Btrfs features in the UI (even to decide which features are relevant enough and deserve to be represented).

Maybe using Btrfs for the root file-system should be a top-level setting like using LVM or encryption.

Maybe we should display some of the Btrfs features (eg. snapshots, transactional, multi-device) as top-level settings without even mentioning Btrfs (it could be considered an implementation detail).

We also need to consider how to represent subvolumes. Maybe as some special property for the root volume at the table of volumes. Maybe with each subvolume being an entry in the table of volumes...

[ancorgs]

In YaST and currently in Agama, "transactional" is actually not something the user can select. Whether the system is transactional or not is decided by the product and/or (in the case of YaST) the installation role.

And "transactional" always implies snapshots. It's kind of a superset. In fact, "transactional" translates into:

• Setting the ro mount option for the root subvolume
• Activating snapshots
• Making sure the transactional-update packages are installed.

[ancorgs]

First question. Do we want to offer the possibility to set a system as "transactional" or should that be only dictated by the product configuration?

I'm more inclined to the second option. Being transactional is likely a feature with too many implications to let the user decide. That being said, I would like the storage screen to reflect that. So let's see how the screen looks now and how could it be changed.

For non-transactional systems we could have something like:

Installation device:  /dev/sda
Use Btrfs Snapshots: [X]
Use LVM: [X]
Use Encryption [X]

That would make disappear the current "with snapshots" label that is displayed as part of the "details" column in the file-systems table. Or maybe we should keep it to make more obvious that snapshots only affect that file-system.

If the product is transactional, it makes no sense to have a control to toggle snapshots. But still it should be clear that we are installing a transactional system.

Maybe mentioning it at the top.

If we remove the "with snapshots" label from the list of file-systems, it would make sense to also remove the corresponding "transactional" one. If we don't remove those labels, maybe we don't need to show anything at the top.

[joseivanlopez]

After some discussions, we agreed a solution to fit the Btrfs options in the storage settings as well as some advanced options like customizing the file systems and space policies.

The idea is to keep the most essential and high level storage configuration in the first storage page, and then to offer a secondary page with more advanced settings.

We want to start offering basic settings because in many cases you don't need to twick advanced options to get your system correctly installed. You only need to select the destination device, what to do with the existing data and possibly some gerenal config like using encryption. The rest of the work is automatically done by the Agama proposal and you don't have to take care.

This first page would contain three sections: Device, Settings and Result. The Device section will allow you to select a disk for installation or a set of disks if you want to use LVM. Moreover, you can decide what to do with the current content of the selected devices (keep, resize or delete). This section will offer a link to the advanced settings just in case you want a more fine grain tuning of the policy to make free space. There also will be a link for activating new devices (e.g., iSCSI, DASD, etc).

The Settings section will have general options like activating snapshots, encryption or TPM. And again, a link to the advanced settings will allow you to define more low level details like the file systems. For example, you will be able to edit the Btrfs subvolumes, create separate partitions (or logical volumes) for some mount points, indicate a different target disk for a mount point, or reuse an existing partition.

[ancorgs]

Only a couple of minor comments:

• Snapshots should mention Btrfs. Btrfs snapshots are a particular kind of snapshots. Not to be confused with, for example, LVM snapshots. And, of course, the usage of those snapshots implies Btrfs is the only option for the file-system type.
• "Enable TPM" is a quite misleading caption. It's actually an encryption setting (which is not obvious in the current layout) and is about relying on the TPM to open the encrypted device automagically during boot without needing to type the password. That's only one of the MANY things you can do with your TPM chip (which is not enabled/disabled via that checkbox).
• I prefer the term "find space" instead of "make space". It doesn't imply you are going to modify things (maybe you already have enough space).

[joseivanlopez]

New mockups including the advanced settings.

Note that adding a file system should allow:

• Create a new file system in the device selected for installation (disk or LVM).
• Create a new file system in another location (disk, existing LVM VG or dedicated LVM VG).
• Reuse an existing file system (from partition or LVM LV).

If an existing file system is reused, then the devices supporting such a file system (partition or LVM PVs) cannot be deleted.

[ancorgs]

After some video-propelled conversations, we agreed on a possible way to tackle of the aspects of the storage proposal in the UI. Including Btrfs aspects and much more. See #1031