On Oct 18, 2012, at 11:55 AM, David Lehman wrote: >>> >> 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.) Not an option. >>> >>> 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. It's not a good analogy. And it's not applicable in any case, no such changes have occurred since inception of multiple device support. >> 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. I still don't understand this. btrfs and md together don't make much sense, certainly not in a gui. People who want functionality not directly offered in btrfs should be pointed to making their own kickstart file, not making you guys do esoteric things, that in fact cause the loss of one of the biggest btrfs features: error detection and correction. btrfs on md raid1 has no ability to correct for detected corruption, the 2nd copy is produced without checksums by the md driver, and btrfs doesn't have access to it. And even on raid0 this is a negative because btrfs still uses raid1 for metadata, but this benefit is lost on md raid0. btrfs on md raid5 is not a basic requirement, and btrfs raid5 is in development now. Anyone this impatient for btrfs + raid5 can use kickstart, rather than polluting your code with unnecessary feature combinations that are vastly more complicated. If Redundancy is selected for a btrfs device, all you need to the *existing* anaconda mkfs.btrfs command is '-d raid1'. If it's not selected the existing line creates a pool of disks with raid0. I don't see how md raid even comes into this, or why it originally did with all new newui code. These features have been in btrfs since 2008. >> >> 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. For mutually exclusive options? Yes radio buttons are rather self-evidently preferable as a UI element because it's immediately discoverable to the user that it's an either/or option. I'd only consider checkboxes if raid10 is supported. And even if you do, you can still use (or later tack on) a 3rd radio button because from a certain point of view raid10 is unique, not merely a combination of raid0 and raid1. In any case, it's not confusing to users to have it as a 3rd option, whereas the present checkbox UI absolutely is. Chris Murphy _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
