|This is the talk page for discussing improvements to the RAID article.
This is not a forum for general discussion of the article's subject.
|RAID was a Engineering and technology good articles nominee, but did not meet the good article criteria at the time. There are suggestions below for improving the article. Once these issues have been addressed, the article can be renominated. Editors may also seek a reassessment of the decision if they believe there was a mistake.|
|WikiProject Computing / Software / Hardware||(Rated C-class, High-importance)|
|The contents of the RAID 5 write hole page were merged into RAID on 2013-01-19. For the contribution history and old versions of the redirected page, please see ; for the discussion at that location, see its talk page.|
|This article was nominated for merging with Non-RAID drive architectures on 2013-02-11. The result of the discussion was not to merge.|
|Threads older than 60 days may be archived by.|
"Inexpensive" vs "Independent"
It correctly states in the article that RAID stands for "Redundant Array of Inexpensive Disks" but then the introduction of the article uses "Independent" instead of "Inexpensive". "Independent" doesn't even make sense. There's nothing independent about a drive in RAID 0, for example. One goes and the data goes. "Inexpensive" is more correct since it describes what is being done. You are taking two or more disk drives and creating a faster, more reliable drive for a lower cost than an individual drive of the same type with the equivalent capacity. If we're going to redefine terms for modernization, RAID should stand for "Redundant Array of Inexpensive Drives" now that we live in a world with SSDs which aren't disks.
The fact that manufacturers incorrectly redefined it is interesting, but that's probably more because some marketing idiot got it wrong and just ran with it without even thinking if it even made sense. If including the incorrect, industry term is important, it should be used as an "or" in the overview with "Inexpensive" being in the primary description since that's what the inventors called it, and not the manufacturers misnamed it.
- The "inexpensive" originates from the historical distinction between a high-performance, highly reliable – and very expensive – hard disk and a standard, commodity one. Since RAID rendered the reliable drive systems obsolete for a fraction of the cost they've vanished in the 1980s. The "independent" keeps the acronym alive and on the other hand indicates that the commodity drives are independent entities or devices, making them easily field-replacable and commonly even hot-swap. This wouldn't be possible with integrated drives (that some reliable drives consisted of). --Zac67 (talk) 04:42, 30 August 2018 (UTC)
Plus one for inexpensive. The introduction of the term RAID was intended to be opposite of SLED (Single large expensive disk.) Unsure where this term "Independent" came from as it does not even apply. If you start taking enough drives out of any RAID setup, you will eventually realize that they are not so "independent." — Preceding unsigned comment added by 2620:15C:203:0:C6D1:A4F0:4D80:129A (talk) 18:17, 30 April 2018 (UTC)
It probably should be both
Although the original usage was "Inexpensive" much of the industry including its consortium, the RAID Advisory Board, adopted "Independent" so I am changing the lede to use both as in BytePyle Tom94022 (talk) 21:36, 15 November 2017 (UTC)
- Indeed, quite often industry gets it wrong: RJ-45 is not an 8P8C modular connector used for Ethernet and a 9-pin D-shell connector is not designated DB-9, to name but two common misuses. 188.8.131.52 (talk) 23:56, 29 August 2018 (UTC)
It should be both as it is
In this case an industry committee redefined the term to reflect the fact that the early RAID subsystems used expensive SCSI HDDs rather than the inexpensive (parallel) ATA HDDs. Somewhat later inexpensive PATA and SATA drives came to be used in "nearline" RAID subsystems while "enterprise" RAID systems continued to use expensive SCSI and SAS HDDs. Today "enterprise" RAID subsystems are almost all expensive SSDs so today "independent" is still the best term not withstanding the term of the original RAID paper. They probably should have changed "disk" to "drive." Tom94022 (talk) 06:23, 30 August 2018 (UTC)
"Inexpensive" is what does not make any sense now or 30 years ago. Do you any of you people contributing to this wiki page have any understanding of how these "independent" disks are used to form an Array of disks? When RAID was first introduced it was primarily used with SCSI drives, which are not what anyone who knows about the technology would characterize as "inexpensive". They were and still are relatively expensive drives as compared to the more common desktop SATA interface. I think what has happened here is some academics have twisted things around because they do not understand the underlying technology and they found something in a document to support their "inexpensive" case. — Preceding unsigned comment added by 184.108.40.206 (talk) 03:48, 20 October 2018 (UTC)
Originally it was inexpensive.
You can see the original paper here: http://www.cs.cmu.edu/~garth/RAIDpaper/Patterson88.pdf RAID was originally a cost reduction method, to allow for the use of cheaper disks than were sold by the then large vendors (IBM and DEC). Parity was added to make up for the perceived unreliability of the cheaper disks. Later when RAID was commercialized, and made expensive by the likes of EMC and NETAPP, marketing efforts to justify the now high prices required the change from inexpensive to independent. You can read one of the original authors (Katz) commenting on the very issue in the last paragraphs of this paper: https://web.eecs.umich.edu/~michjc/eecs584/Papers/katz-2010.pdf — Preceding unsigned comment added by Sciencia61 (talk • contribs) 12:53, 19 June 2018 (UTC)
RAID 1 offers no parity
The article states RAID 1 offers no parity, but a mirror is an even parity. I think it adds no value to explain this to the reader, but maybe it can be corrected? — Preceding unsigned comment added by 220.127.116.11 (talk) 18:54, 19 January 2016 (UTC)
- While technically correct, RAID 1 is never used as parity. To use as parity, the data from both disks would have to be constantly compared -- a large overhead on reads. But even if a miscompare is found, data recovery isn't possible -- there's no indication of which bit is the wrong one. In theory, this might still be done to detect data errors that were never reported by the disks, but for such errors to be common assumes that the disks are unreliable, which RAID 1 would only make worse by having more disks. So, being overhead to implement and providing little help for a type of error that is assumed never to occur, RAID 1 as parity isn't done. --A D Monroe III (talk) 16:20, 5 July 2017 (UTC)
Actually the above comment is wrong on several counts. First a RAID 1 array could have more than 2 members. HP OPENVMS provides this, up to 8 in fact in what they call a shadowset. With more than 2 disks you can catch inconsistent copies. Further it implies that parity systems check parity on reads, they don't. This would require reading the entire stripe, which is too much overhead. With RAID-5 this would be useless as you wouldn't know which version was correct. With RAID-6 some implementations scrub parity in the background, since there are three sources for each block, the block itself, first parity, and second parity. This allows for a voting mechanism. Uncommon RAID systems such as RAID-3 might actually check parity on each read but it is an academic point, there are very few if any commercial versions of them.
As well the article claims RAID-1 read performance is "slower than the fastest drive". In virtually all implementations a read is queued to the disk member with the shortest operations queue. In practice RAID-1 sets give superior read response times and total read rates as compared to single drives. — Preceding unsigned comment added by Sciencia61 (talk • contribs) 12:35, 19 June 2018 (UTC)
Added further quote from SNIA about Write Cache reliability
I added a further reference from the SNIA document explaining that while write caches had a power fail vulnerability, good implementations design for this and add methods to ensure no data is lost. In practice this is almost always a battery backup system, usually with redundant batteries. — Preceding unsigned comment added by Sciencia61 (talk • contribs) 14:07, 19 June 2018 (UTC)