Description of problem: There's no good reason to permit users to create RAID 4 layouts. Even with CLI tools there's no use case for RAID 4, it's used by md as an intermediate step when doing certain conversions between levels, it's not intended to be a final layout. Version-Release number of selected component (if applicable): anaconda-20.27-1 How reproducible: always Steps to Reproduce: 1. Manual partitioning with at least 3 devices selected, Device Type RAID. Actual results: RAID 4 is an option Expected results: It shouldn't be an option. Additional info:
Oops. anaconda 21.27-1.
(In reply to Chris Murphy from comment #0) > Description of problem: There's no good reason to permit users to create > RAID 4 layouts. Even with CLI tools there's no use case for RAID 4, it's > used by md as an intermediate step when doing certain conversions between > levels, it's not intended to be a final layout. [citation needed] > Expected results: > It shouldn't be an option. Why not? RAID 4 isn't as common as RAID 1/5/6, but it's still a thing that people use.
RAID 4 has zero benefit over RAID 5, while having several negatives. Every use case where you'd use RAID 4, RAID 5 is either the same or better. I asked this question on the linux-raid@ list some time ago and there no RAID 4 pros have been raised by any of the RAID developers or experts there. http://www.spinics.net/lists/raid/msg42138.html I would like to have a citation for one person using RAID 4, let them answer the question why they use it and not RAID 5.
(In reply to Chris Murphy from comment #3) > I would like to have a citation for one person using RAID 4 I linked to one the first time, in the See Also field. > let them answer the question why they use it and not RAID 5. I don't have that, but if we're going to design by opinion we can't do both.
Apparently it's already designed by opinion, the opinion of the one who submitted the enabling patch. And the example is for a completely nutty hardware scenario. That certainly isn't a professional or enterprise use case. There's no good reason to let hapless mortal users depending on a GUI installer to do it either. While I have less of a problem with anaconda installing to an existing RAID 4, or via kickstart, a GUI installer shouldn't permit users doing ill advised nutty things like this. Further, QA doesn't have a test case for RAID 4, nor is it in any QA test matrix either, nor does QA have the resources to be testing every possible option exposed in the installer. And my opinion within the QA community is that this feature isn't worth testing resources. It's that esoteric. Only tested, known working features should be enabled in a GUI installer, it's misleading at best and negligent at worst to do otherwise. It makes the installer untrustworthy. So unless the anaconda team does their own testing assuring the feature works immediately prior to release, it should be removed. It is not the burden of users or QA to prove exposed features do not work, it is the burden of the installer's designers to prove exposed features do work.
(In reply to Chris Murphy from comment #5) > Apparently it's already designed by opinion, the opinion of the one who > submitted the enabling patch. And the example is for a completely nutty > hardware scenario. That certainly isn't a professional or enterprise use > case. There's no good reason to let hapless mortal users depending on a GUI > installer to do it either. But this is still subjective. As subjective as the original reporter. Aside from the position that you don't like RAID 4, why would we remove it when there is at least a subset of users using it? > While I have less of a problem with anaconda installing to an existing RAID > 4, or via kickstart, a GUI installer shouldn't permit users doing ill > advised nutty things like this. It doesn't. We follow the approach of giving people just enough rope to hang themselves. If you use the automatic partitioning options, you get the storage stacks that multiple groups have agreed are best practice to be using. If you do custom, well, we can't control all of that. > Further, QA doesn't have a test case for RAID 4, nor is it in any QA test > matrix either, nor does QA have the resources to be testing every possible > option exposed in the installer. And my opinion within the QA community is > that this feature isn't worth testing resources. It's that esoteric. We already know QA doesn't have resources to test everything. This is nothing new. > Only tested, known working features should be enabled in a GUI installer, > it's misleading at best and negligent at worst to do otherwise. It makes the > installer untrustworthy. So unless the anaconda team does their own testing > assuring the feature works immediately prior to release, it should be If we followed this approach, anaconda would do nothing. We absolutely depend on early adopters trying out test releases and nightly builds. Without those contributors, we would not be able to implement about 95% of the things we do support at install time. > removed. It is not the burden of users or QA to prove exposed features do > not work, it is the burden of the installer's designers to prove exposed > features do work. Well damn, let's just close up bugzilla now. I am all in favor of not receiving any more bug reports ever.
(In reply to David Cantrell from comment #6) >But this is still subjective. As subjective as the original reporter. No. It's uncontroversial that RAID 4 provides no benefits over RAID 5. In bug 541433, he wanted anaconda to use an existing RAID 4 array, he wasn't asking for an anaconda UI to create one, therefore this isn't a good example to defend keeping RAID 4 in the UI. Further, he clearly indicated he designated an external USB drive as the parity drive. > Aside from the position that you don't like RAID 4, why would we remove > it when there is at least a subset of users using it? Because like in bug 541433, the only reason to use RAID 4 is to explicitly choose the device used as the parity drive. Anaconda doesn't have a UI for me to do that, therefore the option is useless. And even if it had the UI, it's a pathological option: doing a thing merely because it can be done, not because it's beneficial. > We follow the approach of giving people just enough rope to > hang themselves. This is a treacherous design philosophy for a GUI installer. > If we followed this approach, anaconda would do nothing. That tells me the disproportionate dependency of anaconda on Fedora QA actually enables profligacy. Why should Fedora QA continue to dedicate a disproportionately large percentage of resources testing Manual Partitioning when there are other packages and projects that would benefit from some of QA's attention? A huge percent of release criteria, test cases, text matrix entries, blocker bug discussions, blocker bugs, and blocked releases are installer centered. If the anaconda team neither has QA resources of its own to commit to its own features, nor cares when users hang themselves on such features, why shouldn't Fedora QA only test and block on automatic partitioning? And if anything this is wontfix not cantfix, because keeping it is obstinacy.
(In reply to Chris Murphy from comment #7) > (In reply to David Cantrell from comment #6) > >But this is still subjective. As subjective as the original reporter. > > No. It's uncontroversial that RAID 4 provides no benefits over RAID 5. Far be it from me, as someone who has written significant amounts of RAID code in the past, and who has worked on design of the current md raid subsystem, to disagree with you and the other two people that happened to respond to you on the upstream mailing list (none of whom I recognized from their work on the md raid subsystem), but this statement has no basis in fact. Whether or not raid4 provides any useful role in system deployment depends 100% on the hardware being deployed. For typical deployments, it has a bottleneck problem. That does not rule out atypical deployments. Nor does it make the code useless. > In bug 541433, he wanted anaconda to use an existing RAID 4 array, he wasn't > asking for an anaconda UI to create one, therefore this isn't a good example > to defend keeping RAID 4 in the UI. Further, he clearly indicated he > designated an external USB drive as the parity drive. Which was probably exactly the wrong thing to do, but that's beside the point. > > Aside from the position that you don't like RAID 4, why would we remove > > it when there is at least a subset of users using it? > > Because like in bug 541433, the only reason to use RAID 4 is to explicitly > choose the device used as the parity drive. Anaconda doesn't have a UI for > me to do that, therefore the option is useless. Anaconda also doesn't have a lot of other RAID control knobs. We've talked about adding them at some point in time. For this one, however, a little forethought and the raid4 array can be created ahead of time with the right parity drive and then you can do the install on the existing array. Therefore, it is not useless. This same procedure is also how you enable other features that the Anaconda UI doesn't support allowing you to tweak directly. > And even if it had the UI, > it's a pathological option: doing a thing merely because it can be done, not > because it's beneficial. I disagree. It's not beneficial in the common case, but it can't be ruled out in specific other instances. Persistent Memory architectures coming down the pipe are a prime example of something that could make good use of RAID4 actually. > And if anything this is wontfix not cantfix, because keeping it is obstinacy. No, your demand is ill informed and misplaced.
(In reply to Chris Murphy from comment #7) > (In reply to David Cantrell from comment #6) > >But this is still subjective. As subjective as the original reporter. > > No. It's uncontroversial that RAID 4 provides no benefits over RAID 5. > > In bug 541433, he wanted anaconda to use an existing RAID 4 array, he wasn't > asking for an anaconda UI to create one, therefore this isn't a good example > to defend keeping RAID 4 in the UI. Further, he clearly indicated he > designated an external USB drive as the parity drive. I'd like to point out if this was just brought up as a proposed patch on our mailing list, we likely wouldn't be having this discussion. I honestly don't care if RAID 4 is there or not. Thinking purely about requests that we have received over the years, we have a group that asks for one thing and then another group that asks for that thing to be removed. Who do we cater to? Do we just constantly make every change that is always requested? It would help us if YOU reached out to the original reporter to see if they care about your proposal, then propose the change (perhaps even with a candidate patch), and then we review it and maybe even commit it. Filing RFEs like this in Bugzilla come across on our end like, "YOU'RE DOING STUFF WRONG! DO IT DIFFERENTLY! NOW! I KNOW BEST!" Do you know how many of those bug reports we get? > > We follow the approach of giving people just enough rope to > > hang themselves. > > This is a treacherous design philosophy for a GUI installer. It was hyperbole and a reference to very very old FUDCon discussions, but whatever. Remember that we are talking about _custom_ partitioning. If we expose a bunch of controls to users, we cannot prevent them from destroying their system. > > If we followed this approach, anaconda would do nothing. > > That tells me the disproportionate dependency of anaconda on Fedora QA > actually enables profligacy. Why should Fedora QA continue to dedicate a > disproportionately large percentage of resources testing Manual Partitioning > when there are other packages and projects that would benefit from some of > QA's attention? Because the only way an installer is released is with a distribution release? We have absolutely no other way to get test releases out to users, unlike any other package. > A huge percent of release criteria, test cases, text matrix entries, blocker > bug discussions, blocker bugs, and blocked releases are installer centered. > If the anaconda team neither has QA resources of its own to commit to its > own features, nor cares when users hang themselves on such features, why > shouldn't Fedora QA only test and block on automatic partitioning? We don't have a dedicated QA team on the development side and never have. We are working on implementing continuous integration testing with lots of install scenarios, but we are not there yet. The scope of what Fedora QA tests is not defined by us. If you guys want to test less and label more things as-is, that's ok with me. > And if anything this is wontfix not cantfix, because keeping it is obstinacy. No, it's not a bug. It's a functionality change request. Doug already took care of that.
(In reply to Doug Ledford from comment #8) > Whether or not raid4 provides any useful role in system deployment depends > 100% on the hardware being deployed. For typical deployments, it has a > bottleneck problem. That does not rule out atypical deployments. Nor does > it make the code useless. This bug is about anaconda. It doesn't have the UI to account for atypical deployments, so right now the code is useless. > For this one, however, a little > forethought and the raid4 array can be created ahead of time with the right > parity drive and then you can do the install on the existing array. I already explicitly said I had no problem permitting anaconda to use a RAID 4 array created ahead of time. > > And if anything this is wontfix not cantfix, because keeping it is obstinacy. > > No, your demand is ill informed and misplaced. If that's true you can describe how I can use only anaconda to create a viable RAID 4 array, designating a specific drive as the parity drive.
(In reply to Chris Murphy from comment #10) > (In reply to Doug Ledford from comment #8) > > > Whether or not raid4 provides any useful role in system deployment depends > > 100% on the hardware being deployed. For typical deployments, it has a > > bottleneck problem. That does not rule out atypical deployments. Nor does > > it make the code useless. > > This bug is about anaconda. It doesn't have the UI to account for atypical > deployments, so right now the code is useless. From my reading of the original bug that caused us to add support for raid4 to Anaconda, this is totally untrue. > > For this one, however, a little > > forethought and the raid4 array can be created ahead of time with the right > > parity drive and then you can do the install on the existing array. > > I already explicitly said I had no problem permitting anaconda to use a RAID > 4 array created ahead of time. Then this support has to stay. You can't install to a pre-existing array of any type that Anaconda does not know about. And once Anaconda knows about it, it ends up in things like drop down lists because it's in the list of supported array types. That doesn't mean that Anaconda has all the knobs to support making an array of that type with the precision you are requesting, but it must still know about the array type to even support installing to pre-existing arrays of that type. The original bug was one where Alexandre wanted to install to a pre-existing array but couldn't because the type was unknown to Anaconda. The patch from bug #541433 did not add any specific knobs for creating raid4 arrays, it merely made Anaconda aware of raid4's existence and then Anaconda allowed him to install to a pre-existing raid4 array. So if you support Anaconda installing to pre-existing raid4 arrays, then this bug is NOTABUG, like I said all along. Anaconda has no distinction between raid array types that it supports using as a pre-existing array, or the types that show up in drop down menus or selections. Removing raid4 from one removes it from the other. > If that's true you can describe how I can use only anaconda to create a > viable RAID 4 array, designating a specific drive as the parity drive. Use a pre-existing array. Which, as I just pointed out, Anaconda's current level of raid4 support is both required and sufficient for that purpose, even if the current level of support is not sufficient to control which drive is the parity drive if the array is created by anaconda.
>Anaconda has no distinction between raid array types that it supports using as a >pre-existing array, or the types that show up in drop down menus or selections. >Removing raid4 from one removes it from the other. OK I didn't know that and it's non-obvious because it supports other things like Btrfs RAID 10 yet aren't in the UI. I still think RAID 4 is edge case for a GUI installer and is better left to kickstart like so many other things appropriately are. I'd like to say sorry for the noise. I've asked "why RAID 4?" for nearly two years multiple times on various IRC channels, devel and the anaconda lists, and linux-raid, and all I got were crickets up until this RFE. So it's not like I didn't try other methods first.
(In reply to David Cantrell from comment #9) > Because the only way an installer is released is with a distribution > release? We have absolutely no other way to get test releases out to users, > unlike any other package. For a very long time I've argued Manual Partitioning should be a separate application. It's more useful in contexts other than installing an OS anyway, and there it would get loads more testing than Fedora QA and nightly testers can.
(In reply to Chris Murphy from comment #13) > (In reply to David Cantrell from comment #9) > > Because the only way an installer is released is with a distribution > > release? We have absolutely no other way to get test releases out to users, > > unlike any other package. > > For a very long time I've argued Manual Partitioning should be a separate > application. It's more useful in contexts other than installing an OS > anyway, and there it would get loads more testing than Fedora QA and nightly > testers can. I don't disagree. But this is either a straw man argument with regard to the original RAID 4 request or just a random comment.