Hi folks,
Stephanie, dlehman, and I worked on a redesign of the RAID UI in Anaconda with Doug Ledford's help. I did a blog post sort of documenting the thought process and walking through the latest mock-ups.
Would you mind taking a look and giving us your feedback?
http://blog.linuxgrrl.com/2013/03/11/raid-re-do-for-anaconda/
Thanks :) ~m
On Mon, Mar 11, 2013 at 12:33:24PM -0400, Máirín Duffy wrote:
Would you mind taking a look and giving us your feedback? http://blog.linuxgrrl.com/2013/03/11/raid-re-do-for-anaconda/
It seems promising.
Based on some of the conversations I had with people about LVM-on-RAID, I'm wondering if it might be best to move _entirely_ to LVM as the RAID technology. I think this UI would cover that pretty well, too, without much change.
I really like the link for the disk selection box. I think I'd feel even better if that were represented somewhere visually even without having to click. Would it be possible to show this in some way where the pink and grey available/total boxes are?
On 03/11/2013 04:08 PM, Matthew Miller wrote:
Based on some of the conversations I had with people about LVM-on-RAID, I'm wondering if it might be best to move _entirely_ to LVM as the RAID technology. I think this UI would cover that pretty well, too, without much change.
What do you mean by this? Are you referring to LVM's built in mirror/stripe ability? If so, IIUC, it only covers the equivalent of RAID 0, RAID 1, and RAID 10, not the others, so it doesn't make sense to me to throw mdraid out in favor of it (is that what you are proposing?)
I really like the link for the disk selection box. I think I'd feel even better if that were represented somewhere visually even without having to click. Would it be possible to show this in some way where the pink and grey available/total boxes are?
Unfortunately there isn't a scalable way to do this; we've brainstormed about it before. If you have any good ideas though they are most certainly welcome.
~m
On Mar 11, 2013, at 2:08 PM, Matthew Miller mattdm@fedoraproject.org wrote:
Based on some of the conversations I had with people about LVM-on-RAID, I'm wondering if it might be best to move _entirely_ to LVM as the RAID technology.
LVM supports linear (default), mirror, and stripe and combinations. No RAID 5 or 6.
Are many people using LVM mirroring and striping? The command line syntax for managing LVM mirroring and striping is distinctly unlike mdadm syntax. And (md) linux-raid@ is quite active helping users with problems. Is that the case for LVM mirroring and striping? I think there need to be overwhelmingly good reasons to use LVM native mirroring/striping instead of md.
But the updated RAID UI looks like it'd have LVM RAID choosable by changing the Technology pop-up menu to LVM. Then I'd expect to see 2-3 options: linear (or no selection), mirroring and/or striping.
– I'm interested what the LVM on (md) RAID UI will look like, currently they're separate and mutually exclusive features.
– I'm unclear about the distinction between the Partition Type: (RAID) pop-up meaning, compared to Technolgy: (RAID).
– I still think RAID 4 needs to be dropped. It's not as bad as letting users create a degraded array and install to it, but there's no user use case for RAID 4. It's used as an intermediate format when converting between certain other RAID levels.
– Overall I'm not too concerned about the exceptional amount of descriptive text. If there were an elegant way to hide the smaller point descriptive text and show it as a tooltip/mouseover that might be better.
– Descriptive text says RAID 6 requires minimum 3 disks, but it needs 4 minimum.
Chris Murphy
On Mon, 2013-03-11 at 16:08 -0400, Matthew Miller wrote:
On Mon, Mar 11, 2013 at 12:33:24PM -0400, Máirín Duffy wrote:
Would you mind taking a look and giving us your feedback? http://blog.linuxgrrl.com/2013/03/11/raid-re-do-for-anaconda/
It seems promising.
Based on some of the conversations I had with people about LVM-on-RAID, I'm wondering if it might be best to move _entirely_ to LVM as the RAID technology. I think this UI would cover that pretty well, too, without much change.
This is very similar to the problem of encryption with lvm in that there are two general approaches: you can encrypt the entire VG (by encrypting the PVs) or you can encrypt individual LVs. Likewise, with raid, you can make a single PV on an MD device (which will apply the raid features to the entire VG) or you can apply raid features to individual LVs using the segment type options to lvcreate. We have more or less signed up to support both approaches to encryption, so I expect we'll want to do the same for raid/lvm.
David
Hi,
On Mar 11, 2013, at 9:33 AM, Máirín Duffy wrote:
Would you mind taking a look and giving us your feedback?
http://blog.linuxgrrl.com/2013/03/11/raid-re-do-for-anaconda/
I think the UI looks really good and much cleaner! The explanations help a lot, but it's a lot of text and looks a little bit overwhelming. Maybe we can have a help button or something instead?
-Stephanie
LVM supports linear (default), mirror, and stripe and combinations. No RAID 5 or 6.
There is some confusion on this point.
Both upstream and (backported to) RHEL 6.3+ have added LVM segtypes for MD managed "raid1", "raid4", "raid5", "raid6" plus (also backported to 6.4) "raid10". In other words, instead of putting LVM atop of MD, you can now have all of your drives as PVs in a VG, and then decide how you want individual LVs to be carved up from the PVs. Using these new LVM "raid#" segtypes use MD by using subvolumes (on each PV) of Extents for data, parity, etc..., plus an Extent for metadata.
See "man 8 lvcreate" and "man 8 lvconvert" if your distribution provides support for these new "raid#" MD managed segtypes (--type option). The RHEL documentation also covers these features [1], as well as how to convert LVM mirror to MD raid1 as a managed LV. [2]
I won't speculate on what some might want or would recommend in an installer, that's not my place. I just wanted people to be aware this support is already in RHEL 6.3+, in addition to upstream, since some were not aware of it.
-- bjs
[1] https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/ht... [2] https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/ht...
On Mar 11, 2013, at 5:15 PM, Bryan J Smith b.j.smith@ieee.org wrote:
See "man 8 lvcreate" and "man 8 lvconvert" if your distribution provides support for these new "raid#" MD managed segtypes (--type option).
Interesting. Looks like the man pages at die.net are out of date. The functionality and documentation is in Fedora 18 however.
I won't speculate on what some might want or would recommend in an installer, that's not my place. I just wanted people to be aware this support is already in RHEL 6.3+, in addition to upstream, since some were not aware of it.
Thanks for this. I'm looking over the nomenclature and syntax used and it's quite different from mdadm when it comes to creating and managing arrays (grow, add device, convert level, failed/failing devices, getting info on). That's a concern I still have, but there are clearly big advantages of the integration.
If it weren't already in RHEL, I'd be inclined to think it's too soon for F19 to implement "RAID LVs" rather than LVM on an md device. But maybe that's exactly what the anaconda team has in mind for "LVM on RAID"?
For managing, it's a huge change from what users are used to, which obviously doesn't mean "don't do it" but it's just a big change. The complaints about anaconda 18 lacking LVM on RAID as a regression from 17 are pretty minimal.
Does the LVM implementation have device failure notification? I'm not seeing the equivalent of md sending a failure email in the lvm.conf.
Chris Murphy
I think the UI looks really good and much cleaner! The explanations help a lot, but it's a lot of text and looks a little bit overwhelming. Maybe we can have a help button or something instead?
This is my main concern, too. One of the pieces of feedback we got at Devconf in Brno was that some of the dialogs have too much text so they did not get read. I am worried that is what's going to happen here. In general, I don't think in-anaconda is a great place to try to educate the user.
- Chris
anaconda-devel@lists.stg.fedoraproject.org