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.
Physical partitioning
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.)
Pre-existing partition
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.
Maybe. Does it work for you?
(Another note: we’ll read linear RAID on pre-existing RAID disks but we won’t let you create it since LVM & btrfs are available.)
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.
LVM
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.
BTRFS
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.)
BTRFS volumes
This first mockup shows the details for a BTRFS volume. As mocked up it’s RAID options for BTRFS not mdraid underneath.
BTRFS subvolumes
Now we have a subvolume selected. Subvolumes don’t have labels so that field is taken out.
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
In the previous screen, if I selected “sub-volume” from the first dropdown, the dialog would change slightly for me.
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?
it looks great! you are making history..
Thanks 🙂
Thoughtful ideas – well laid out.
I have a question unrelated to the ideas – what software did you use to make the nice diagram entitled: “Anaconda Storage Screen Flow”
Thanks for the kind words! I used Inkscape to create the diagrams with the help of an SVG template you can find here: http://www.jjg.net/ia/visvocab/
thank you for your openness and the quality link – it is appreciated.
Two comments:
Wouldn’t it be more useful to show summary of autoselected partitioning scheme in the first page instead of just “You’re all set”? This way advanced user would immediately know if/when they need modify partitioning scheme. As a power user I would definately go to modify partitions if software just claims to do the best for me behind my back, but if the software says this set X, Y and Z is the best, then I can think that okay, sounds good, go with it…
And you used “automatic data backup” for data redundancy. It is not backup, RAID/lvm/whatever data duplication is not a replacement for backups…
Yeah, I think the summary is a good idea. Maybe not too in-your-face for folks who just want to click next and forget it, but maybe put it under a disclosure triangle.
I agree ‘automatic data backup’ isn’t the best term to use for redundancy… we were talking about that over the whiteboards, I think we need some better language there. Although to be fair, the point of redundant data is to have a backup in case a drive fails…
Since you took my first comment so well I thought I would offer my comments again. These are sincerely meant as constructive criticism. These mockups are a considerable step up from the current anaconda interface and I can see some considerable thought has gone into them.
9-3-1-1
Protect Data sounds, to me, like something to do with disk encryption.
How about “Keep Existing Data” instead? This should probably be enabled by default for /home, etc. (perhaps for every partition except /, swap and boot).
What if I want to non-destructively resize a partition? I want to keep my data, but also change the capacity.
The “Any data on this drive will be lost.” text – presumably this actually refers to the selected partition rather than whole physical drive? In that case, if you are using the term partition in the rest of the interface, I would use it here too to avoid confusion. If you really do mean the whole drive will the text be updated to “Some data on this drive will be lost”, etc. if the user decides to keep some partitions intact?
If you colour the partitions (which looks nice in your mockups), then you need to highlight the selection partition using something other than colour. After staring at the mockups for a while I see you’ve already done this with a little arrow under the selected partition. I didn’t notice this at first and it took me a while to figure out which partition was selected, although I can’t think of a better alternative.
With the accordian layout it was unclear to me at a glance that the greyed out bars at the bottom of the screen represented other disks that were to be partitioned. May I suggest you try putting an icon of a hard disk (or even better the appropriate icon for the type of disk – e.g. a picture of an external USB hard disk enclosure for an external USB drive) to the left of each of the grey blocks? It might make the layout look a little unbalanced, but I think it’s worth a try to see.
How about a short description (or hyperlink with description) next to the filesystem drop-down? If the installer gives me options, EXT4 or BTRFS, how am I to decide? I would like to see the pros and cons so I can make an informed decision. Of if one is clearly better, don’t ask and always use that one!
9-3-1-2
I know that vertical space is an issue here because of the accordian design, which is probably why you have laid out the “Add a partition” and “Add this space” options horizontally. However mutually exclusive options are usually shown vertically. In this case my eye is drawn to the “Add this space” section as it is in the centre, and “Add a partition” looks, in my peripheral vision, like some additional options for “Add this space”. Short of not using the accordian, I’m afraid I don’t have a useful suggestion of how to improve it though!
9-3-1-3
The options in this dialog are duplicated from 9-3-1-1. I wonder if, with some fiddling, it would be possible to include them in-line in 9-3-1-2. Perhaps using accordian in an accordian (actually, on second thought, forget I ever suggested that!)
9-3-2-1
What I am looking at in the box on the left? (needs a heading). I would suggest moving the Filesystem, Mount point and Encrypt options to be grouped with the Capacity option, as in 9-3-1-1 and 9-3-1-3 such these four options have the same layout in all the screens. If you need to make space for them there, then how about moving Physical Members to a separate pop-up dialog and just putting a summary on this screen? (especially if anaconda is going to populate them automatically).
9-3-2-3
Again I would use the same Capacity, Filesystem, Mount point and Encryption layout for all screens.
9-3-3-1
Since partitions are, in a sense, logical disks I think using “Logical Disks” for the LVM tab is confusing. Since all these screens are really for advanced users I would spell out the technology explicitly and say “LVM Volumes”, or perhaps “LVM Partitions”.
9-3-4-1
Again I think this should be “BTRFS Volumes” or “BTRFS Partitions” rather than “BTRFS Disks”.
9-3-4-3
I wouldn’t say the inconsistency is horrible, but it sure is inconsistent all the same! Does it need to be? On the other hand the user is likely to select ONE of Software RAID, LVM Volumes or BTRFS Volumes, so they will probably never notice the inconsistency. All the same it would be nice to have the same user interface flow for all the tabs.
Holy moly this is great feedback again Chris! I’m gonna pour over this the rest of this week and try to incorporate your suggestions / address the issues you identify here. Thank you *so* much!
Looks great.
I’d like the option to set labels to physical partitions at install time, and I suggest the default label for the partition will be either it’s mount point or the device name. What do you think?
I think maybe the mount point is better; sometimes the device names are kind of crazy!
yes, I agree, but I’m not sure it’s possible to include / in the drive label (haven’t checked though).
I would like access to advanced features if possible. I love the idea of simplicity and I do believe Fedora and RHEL can become easier in some areas. But it is important to remember that many sysadmins of other operating systems uses Linux tools and other third party tools to administrate partitions, disk images, and disks. That is not a clear sign of greatness for those operating-systems.
The first version of Red Hat Linux I can find at home is 3.0.3 (Picasso, 1996) and I have done RHCE. But that doesn’t really matters. What does matter is the needed flexibility for advanced users, but at the same time the need for a easier, less error prone, and more effective work flow than today.
Access to advanced features should be easily available, but strongly marked as what it is. I do not believe it should be some strange or hidden feature. Just a feature that is there to use, but not encouraged.
Thank you for working on this important part of the system.
Hi, didn’t read the entire article, but wanted to make a reminder for one side topic: does the manual partition dialog create partitions aligned for 4kb blocks, which is useful for newest hard drives?
See http://lwn.net/Articles/377895/ and http://www.ibm.com/developerworks/linux/library/l-4kb-sector-disks/index.html?ca=dgr-lnxw074KB-Disksdth-LX for details on this topic. I suppose the automatic partitioner will do that already but could you check that this is also done with manual partitioning?
You’re asking what uses are there for doing a different RAID, etc. setup for different partitions. Personally, I tend to install my servers using only RAID1 for the root partition and reserving higher RAID levels, LVM, etc. for non-root partitions. That way, if there is a problem (initramfs, etc.), I know that I can at least boot into the root partition and attempt to fix it.
[…] from a discussion in #anaconda with dlehman where we pondered over the overall flow / navigation of the advanced partitioning screen mockups in Fedora’s installer after showing them to Spot and lmacken and uncovering some issues. Will this go anywhere? No idea. […]
[…] from a discussion in #anaconda with dlehman where we pondered over the overall flow / navigation of the advanced partitioning screen mockups in Fedora’s installer after showing them to Spot and lmacken and uncovering some issues. Will this go anywhere? No idea. […]