I'm guessing your mail bounced when you tried to send it to anaconda-devel since you're not subscribed. I think you have to be subscribed to post. I'll comment inline: On 12/19/2012 04:26 PM, Marian Ganisin wrote: > On this screenshot (attached to original bug): > https://bugzilla.redhat.com/attachment.cgi?id=640017 > > First checkbox has label 'Redundancy', last checkbox has label 'Redundant'. In my understanding same terms. Additonally they aren't different by any means, just two equivalent checkboxes for 'redundancy' in same group. > Btw that 'RAID6' label visible on the screenshot does not bring any light to selected configuration. They're not in the same group. The first checkbox you're referring to is the Redundancy checkbox for data redundancy. The second one, you'll note in the screenshot, is indented under the 'Error detection (partity)' checkbox. It is a child of the error detection checkbox, and means redundant error detection / partity, not redundant data. I'm sorry that the two similar words confused you. Maybe we can indent the parity options a bit more so it's clearer they apply to error detection, or grey them out unless error detection is selected. >>> * error detection is feature of all RAIDs but RAID0, levels can't be >>> differentiated >> >> This is incorrect, Marian. Neither RAID0 or RAID1 have error detection. >> >> https://en.wikipedia.org/wiki/RAID#Standard_levels > > Linked section does not seem to mention error detection for any RAID > level at all (maybe following table, however that clearly states RAID1 > is able to detect/tolerate failure of n-1 drives which is far away best > error detection/correction from all other levels). First of all, the user interface clearly identifies the error detection type we are talking about as "parity." The label for the option is "Error detection (parity)." The link I pointed you to states: "RAID 0 (block-level striping without parity " "In RAID 1 (mirroring without parity" > Contrary last sentence of top-level initial paragraph of same wiki page clearly states: > > RAID levels > 0 provide protection against unrecoverable (sector) read errors, as well as whole disk failure. Yes, they do. That is because they are either mirrored or feature parity. Just because you've mirrored your data and have a spare copy when one device fails, doesn't mean you're using a RAID level with parity. > Additionally md manual page (try man md or read http://linux.die.net/man/4/md ) states exactly same in section RECOVERY: > > If the md driver detects a write error on a device in a RAID1, RAID4, RAID5, > RAID6, or RAID10 array, it immediately disables that device (marking it as > faulty) and continues operation on the remaining devices. Again, this is *not* equivalent to parity. >> If you read comment #10 again, you will see I wrote the following: >> >> in the RAID # format ("common terminology"). >> >> I was referring to the RAID # format (RAID ), RAID 5, RAID10, etc) as the "common terminology" as that was what Martin called it in comment #0. > > This confusion is caused by insufficient description of my intention, that's my fault sorry for that. I'll try to correct it. I absolutely agree with initial reporter of reffered bug, Martin Banas, that common terminology is crucial for easy adoption of new RAID handling. In my opinion it is absolutely necessary to bring similar naming as other products providing RAID capability such as BIOS RAID, full featured RAID controllers or other operating systems. I am afraid that terminology introduced in new anaconda isn't used by any similar product and as such it tends to be highly confusing (it is highly confusing to me for all expressed reasons). Therefore I asked to show usage of approach also in other products. I hope it is much clearer now. You've completely lost me here. I'm sorry again that you apparently did not understand or read carefully what I wrote in the bug. > Well, this is it. Last but not least initial message of bug https://bugzilla.redhat.com/show_bug.cgi?id=874068 describes issue with current implemetation of RAID definition in really specific comments as is and it does not deserve to be closed/rejected without further discussion/research. I closed the bug, as I explained twice in the bug, because we cannot fix it for Fedora 18 and will not be able to revisit it until we do the usability research I mentioned in the bug. Yes, we will do research and gather data on the issue. Just because I closed the bug doesn't mean that isn't going to happen. > As the anaconda implements creation of MD devices it would be really nice to have it aligned with MD terminology as expressed in relevant man pages. You've missed the point. ~m _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
