So, last time we chatted about Fedora’s installer redesign, we walked through how users would select which disks they’d like to be part of the install.
Once our intrepid installer users have selected disks to install to, they should be set and the install will just work. (Okay, there’s the case where they have to squeeze space out of existing filesystems owned by another OS, and that’s in the plan, but not for this blog post.) In either case, these folks will not have to encounter screens like these at all. Some users, though, prefer to review and/or manually modify the disk partitioning, so this set of screens is what those users opt-in to see. So, most users simply trying to install Fedora on their laptop won’t ever have to bother with these screens unless they really want to.
The way it’s mocked up now, they are tabs across a single screen. Serving up partitioning buffet-style like this is not ideal in my opinion, because then we’ll be enabling users to do things like btrfs raid on top of md raid which can, if I understand correctly, eliminate some of the advantages of having RAID in the first place. Buffet-style partitioning also enables a scenario in which you create an md raid device that you then put in an LVM volume group that has a logical volume which you place into a btrfs volume… Is there a point to that? If not, then why make it so easily achieved?
So, what we talked about in #anaconda today is that we could change these mockups to include some screen where you choose one of the following four options:
- Physical partitions only
- mdraid partitions only
- LVM only (with raid option that uses mdraid under-the-covers on the physical volumes)
- btrfs only (with raid option that uses mdraid under-the-covers… btrfs raid doesn’t support raid 5 and is also not as stable as mdraid; this also avoids layering raid on top of raid in counter-productive ways.)
dlehman referred to this approach as being the python (‘there’s only one right way’) philosophy instead of the current perl (‘there’s more than one way’) philosophy. I have to say as a designer I really like the python approach better as it seems less error-prone and more focused on the end solution; the more meanderings we support, the more pits of snakes we set up for users to potentially fall into.
But maybe restricting users to those four partitioning flavors doesn’t make sense. What if I want my root filesystem to be physical partitions only, but I want my homedirs to be raided btrfs? Is this sensible? I don’t know. I don’t know why I would want to do that, really. Maybe we could offer a fifth, “you’re on your own, buddy” option that enables the full buffet. Oh and ouch. What do you do if you have a little smorgasbord of a partitioning scheme pre-existing on your disks…?
Well, in any case, if I want a complicated setup, I could always create it via kickstart, which is perhaps some solace.
Okay, so let’s get to the screens already now that I’ve undermined them with worrisome hemming and hawing. I have been staring at them far too long and need your unbiased, untainted, sensible opinions to move forward, I think.
How do I get here?
In the previous set of mockups for disk selection, the terminal screen of the 2 flows where you have enough disk space give you a checkbox to opt-in to see advanced partitioning:
So you check off the checkbox and hit continue, and you end up on this lovely little (terrifying) partitioning path shown in the diagram below under the 9-3-x box.
We had 7-8 variations on this that we worked through before we arrived at this; a custom accordion-style widget with an entry per-disk. When a row is expanded, a draggable-graph for the physical disk is displayed with an options panel underneath that is attached to individual partitions via a speech bubble tail.
There are two main cases here: you’ve got a pre-existing partitions you’re looking at, or you’ve got blank space on a disk that you’ve clicked on. (by default the options bubble is displayed for the first partition on the disk.)
Since you may have data on a partition that you don’t want compromised, there’s a notion here of a ‘protect data’ lock. By default, we were thinking we’d apply it to all pre-existing partitions. If a partition is protected, than destructive operations such as changing the filesystem or capacity will be greyed out in the options pane; you could change the mount point for protected partitions though, since that shouldn’t hurt it.
Free space on a disk
So if you happen to select free space in the graph, you’ll be given the option to create a new partition out of it, or distribute it across other existing partitions (either proportionally or evenly… maybe icons would help illustrate the difference. Proportionally by default.) If there are no other partitions, you’ll also get an ‘other options’ link that, if you really want, will enable you to create an unpartitioned filesystem.
Creating a new physical partition
So if you click on ‘add partition’ from the free space options panel above, or if you clicked the ‘add partition’ button in the top right of the graph for a disk, this is the screen you’ll get. You can optionally drag out space for your new partition in a graph of the disk or just use the slider widget below it.
Redundant arrays of inexpensive disks (via mdraid)
Next up is the software RAID tab. The general layout here, which you’ll see in the LVM and BTRFS tabs as well, is that there’s a pane on the left that lists out the devices and a details pane on the right specific to the currently-selected device / volume / etc.
Raid device details
We’ve got a departure from the current Anaconda way of doing things here. Today, if you want to create a raid device, we first require that you create RAID partitions individually. Once you have enough free RAID partitions, we ungrey-out the create RAID device option and let you put them together.
- Problem: The current way will let me RAID together a 1 MB RAID partition with a 1 GB RAID partition, which will literally waste 1 GB – 1 MB worth of disk. No warnings or anything, either.
- Solution: You won’t have to be in the business of creating individual RAID partitions anymore. Tell us the RAID features you want (mirror, stripe, parity, etc.), and tell us how much disk capacity you want in the end, and we’ll handle creating the RAID partitions for you, making sure they are the right size and are also equal sizes so no disk space is wasted.
Add a new physical member to a RAID device
If you want to add another physical member to a pre-existing RAID device, you click on the ‘+’ button at the bottom left of the physical member list on the RAID device’s details pane, and you’re offered potential slices of unpartitioned disk space to choose from. When you add it, we’ll automagically make the new RAID partition the correct size to match the other members of the RAID device.
Creating a new raid device
If you want to create a completely new RAID device, you click on the ‘+’ button in the bottom left of the left pane, and you’ll get this lovingly complex dialog that offers up in human terms, not RAID level numbers, the various possible RAID features you might want with the rationale for each (why stripe? better performance.) Depending on what options you pick, you’ll end up with a different RAID level… we’ll display the raid level in a status area above the buttons along the bottom of the dialog.
If there is no way, no how you could reach particular RAID levels because you don’t have enough physical disks selected, the appropriate RAID options will be greyed out. If you only have one physical disk, for example, no mirroring (nor a false sense of security) for you.
The LVM tab follows a similar pattern to Software RAID, and you’ll see it under the BTRFS tab as well. One difference in the left pane is we now have a tree-like view, where the parent items are volume groups. You can select either volume groups or individual volumes in the left pane. Depending on what you’ve selected on the left, you’ll see details for it on the right.
LVM logical volume details
Here’s the details pane for the lv_home logical volume. As mocked up now, the striping and mirror options are those built into LVM itself, not any kind of mdraid layered underneath.
When adding physical members to a logical volume, you can, if you want, switch volume groups or create a new volume group. (Maybe this is weird and awkward. It’s inspired by how the RAID works – you don’t deal in RAID partitions, only RAID devices. Here, you don’t deal in volume groups, just logical volumes; you only deal with volume groups in a way that supports logical volumes. I’d rather users not have to deal with volume groups at all unless they really wanted to.)
LVM volume group details
If you click on a volume group in the left pane, then you get the following details pane. You can create a logical volume under the selected volume group with the button in the upper right; you can edit the physical members; you can change the label, change the extent size, or reserve space for later logical volume growth.
Create a logical volume
So here you create a new logical volume, and by default it’ll become a member of the volume group over whichever logical volume was selected when you pressed the “+” button to add a new one. However, in the dropdown next to ‘physical members’, you can pick a different volume group for it to be a member of or create a new volume group for it.
Create a new volume group
This is actually just the previous screen still, but it shows you what happens when you decide to create your new logical volume in a new volume group. A text field for the group’s label appears below.
Add a new physical volume
Need more capacity in your volume group / logical volume? Add a new physical member to it. This is the dialog you’ll see if you do that. Although I’m not sure it’s entirely valid to exclude physical partitions now that I think about it.
The BTRFS tab has a full-blown treeview in the lefthand pane, but this is solely because BTRFS supports nested subvolumes. We won’t be allowing the creating of nested subvolumes, but we will have to read them if they exist. I think it would be nice if there are no nested subvolumes on disk that we could use a non-treeview widget here since reading pre-existing nested subvolumes is really an edge case. (Alternatively, always show a flat list in the left pane, but if a given subvolume has nested subvolume children have a list in the details right pane that displays all the children.)
Adding a BTRFS volume
When you press the “+” button in the lower left of the lefthand pane in the BTRFS tab, you could add either a BTRFS volume or a BTRFS subvolume. The first choice in this simplified creation lightbox is either volume or subvolume. The philosophy here, which is a bit different than adding new logical volumes or new RAID devices, is to ask the bare minimum of details and allow the user to fill in optional stuff after the new volume is created. Is this inconsistency horrible? Maybe!
Adding a BTRFS subvolume
Adding a new physical member to BTRFS
Need more space? Then you need to add more disks/devices. This is what it looks like if you press “+” on the list of physical members of a BTRFS volume or subvolume. This is the most permissive of the ‘add new physical member’ dialogs; it’ll show LVM logical volumes, RAID devices, partitions, etc.
These all need more work…
…for sure, but hopefully this is a decent start. What do you think?