On Thu, 2012-10-18 at 11:31 -0600, Chris Murphy wrote: > On Oct 18, 2012, at 9:21 AM, David Lehman wrote: > > > On Wed, 2012-10-17 at 22:03 -0600, Chris Murphy wrote: > > >> a.) By default neither one is checked, which doesn't make sense. Optimized performance (stripe) is the btrfs default for multiple device volumes. > > > > This kind of thing is very irritating. First of all, it makes sense -- > > just because btrfs-progs has one default doesn't mean that any other > > default is nonsensical. > > Very irritating? Please explain how it makes sense. There are only two possibilities for two disk btrfs volumes: raid0, and raid1. Yet the UI implies there are three possibilities. Is the third not-raid? Please explain how to create a 2+ device btrfs volume with not-raid. What about linear without striping? Not an option? (I haven't read btrfs docs for quite a while now and I don't remember.) > > > > Second, I'm not too keen on chasing the > > btrfs-progs defaults. See, they can change as often as they like and I'm > > not interested in signing up for the game of keep-up. Someone other than > > me may find the desire or time to implement this, but it's not likely to > > be me. btrfs is starting to seem like a high-maintenence woman, except > > without all the wonders of womanhood. > > I don't see how your misogynistic stereotypes are applicable. mkfs.btrfs <device1> <device2> etc. has always used raid0 by default for data, and raid1 for metadata. It has been this way for 4.5 years. I'm aware of no plan to change this, or what they'd change it to. Wow. I'm not sure how you turned that into misogyny -- my intent was exactly the opposite. Some people and things are high-maintenance. My point is that some are quite worth the trouble while others are not. > > > >> > >> b.) When I check Redundancy on Root and/or Home, and then click back to the other, Redundancy is unchecked. So the checkbox isn't sticking. > > > > I've been thinking about this. I don't like exposing options for the > > parent/container in each its children. It's confusing at worst and weird > > at best. > > You're right, this is confusing too, but that's actually not what I'm referring to. > > When I check Redundancy for Root, then click on Home, then click back to Root, Redundancy is unchecked. > When I check Redundancy for Home, then click on Root, then click back to Home, Redundancy is unchecked. Now I see what you're talking about. > > The boxes are no longer sticky in 18.18. This is new behavior from 18.16 where they were sticky, but didn't make a difference to file system creation. > > > > For F18 I'll have to come up with something that won't take too > > much time -- maybe just make sure the changes are saved/reflected across > > subvols. > > That's fine. You're sorta stuck with an overly complicated custom partitioning UI that lets users do nonsensical things just because they want to do them, like ext4 boot and btrfs root and xfs home. Simplification after the fact inevitably leads to discontinuities. > > > Eventually it will make sense to be able to specify subvolume > > versus volume as device type and only provide the volume-level options > > in the volume editor. > > Eventually, it's expected to have per subvolume, and per-file RAID levels. That would obviate the need for separate volumes. If per-subvol raid appears before we've removed raid options from subvol options, great. If not, we'll still be improving in the meantime. > > > > >> > >> c.) I can choose both options for just two disks, and btrfs raid10 requires 4 disks minimum. The checkboxes don't stick. > > > > I guess I'll have to disable that for now, then. At some point I may > > have time to flesh out the btrfs-specific raid backend, but for now it > > goes to the back burner. See the high-maintenance remark above. > > The btrfs raid backend has exactly three data raid options: -d raid0 (the default), -d raid1, and -d raid10. That's it. There's nothing else to it but to specify the devices. By keystrokes it's in the realm of 100x simpler than md raid. Yes. It's far simpler if you isolate it from the world around it. This isn't physics class. My point is that we already have all this raid code from md which we're currently using for btrfs as well -- if the btrfs stuff is going to require significant additional work in that specific area, it'll have to wait til we have time for that. > > > > > >> > >> Honestly for 2-3 disks, the simpler UI is a radio button, not checkboxes. > > > > Having two different UIs depending on the number of disks is not > > simpler-enough for the user to justify the madness for the developer, so > > that's not going to happen. > > Then use three radio buttons: raid0, raid1, raid10. Gray out all except raid0 for 1 disk. Gray out raid10 for 2-3 disk. And make them all available for 4+ disks. > > I have no complaints about raid10 not being available in F18. Two radio buttons for raid0 and raid1 is sufficient I think. Got it. You like radiobuttons for this. It is entirely possible we'll change this drastically at some point, and also possible we'll use radiobuttons when we do. > > > Chris Murphy > > _______________________________________________ > Anaconda-devel-list mailing list > Anaconda-devel-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/anaconda-devel-list _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
