Re: F18 beta TC4 btrfs options

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.


> 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.


>> 
>> 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.

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.

> 
>> 
>> 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.


> 
>> 
>> 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.


Chris Murphy

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list


[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux