With the caveat that any changes suggested have close to a 0 chance of getting into F18 since we are well past string freeze and non-blocker freeze and some of the developers have already left for the holidays. (Thanks for suggesting a few concrete ideas, though): On Thu, 2012-12-20 at 05:00 -0700, Chris Murphy wrote: > 1. I suggest exchanging "Redundancy (mirror)" for "Mirroring". > Redundancy applies to RAID 1, 4, 5, 6 so using it as a primary term is > confusing. If this checkbox means RAID 1, then it really ought to say > just "Mirroring" or "Mirroring (RAID1)". Swapping 'Redundancy (mirror)' for 'Mirroring' seems like a reasonable change to me, especially if it makes the label less confusing. Would you be willing to file a bug for this under F19? > 2. "Optimize performance (stripe)" I think it's more clear if this > "Performance optimized striping" if this is meant just for RAID 0. It's not just meant for RAID 0. > 3. "Error detection (parity)" is a confusing label. Parity applies to > md RAID 4, 5 and 6 and I can check this option by itself with nothing > else checked which then implies RAID 4 which is so uncommon that > supporting it doesn't make sense. Once selected I can't deselect it; > and I can't select either option below. But I can select the two > options above. So upon checking this, I have RAID 4, and can choose > either RAID 41 or RAID 40, which are even more rare than RAID 4. While I understand your concern that the arrangement of checkboxes allows for more rare RAID configurations, a flat list of RAID levels also treats more rare levels at the same level as the more common ones so the base problem here is the same. > > Error detection itself is misleading because in normal operation RAID > 4, 5, 6 themselves do not detect any errors above what the drive > firmware detects (which is the same for RAID 1 and RAID 0). In order to > get error detection the user must initiate or schedule a scrub or > repair. Conversely, Btrfs does have error detection which is active > during normal operation regardless of the profile used. How would you suggest changing the label? > > Error correction is true, but it's also true for RAID 1. > > 4. "Distributed" parity applies to RAID 5 or 6. It's unclear which I'll > get, or why I can select it all by itself with no other options > including without Error detection (parity) selected. > > 5. "Redundant" under Error detection is confusing. RAID 4 is redundant, > RAID 5 is redundant, RAID 6 is redundant. I'd guess it means RAID 6 > except… It's indented under parity, meaning redundant parity. Marian had this confusion as well, so I think we need to tighten up the visual design there and perhaps grey out those two sub checkboxes unless error detection (parity) is active, perhaps even change the labels to 'redundant parity' and 'distributed parity' > 6. I can't choose both Distributed and Redundant, also very confusing, so Redundant must not mean RAID 6. I think you should be able to choose distributed and redundant to get 6 (distributed only for 5), so this may be a bug. > > Items 3-6 I think need to be consolidated into just RAID 5 or 6, and > skip RAID 4. As for what plain language to use to describe them, it's > difficult. "Single drive fault tolerance" is maybe OK, but that applies > to a two disk RAID 1. If we drop RAID 4 I'm sure we'll get more self-righteous hate mail. Can I blame you and provide your email address if we do this? :) > And possibly the best multidisk options, which are also the easiest and > fastest to grow when more space is needed: linear, and RAID 1+linear, > combined with XFS for parallelization. But this isn't an option at all. If XFS is a supported fs type (I don't know if it is offhand) you could select RAID as a partition type and XFS as the filesystem, using RAID for the technology dropdown. ~m _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
