Talk:RAID

References

IEEE.org as of 4-6 Dec 1991 and updated as of Aug 2002 cited Inexpensive,

IEEE.org as of June 29 2009-July 2 2009 and updated as of 29 September 2009 cited Independent,

NetApp -Independent

EMC - Independent

Western Digital Independent

A paper from Duke University Dept. of Computer Science in 1993 - Inexpensive

Edit revert

I have reverted two edits by 145.225.17.100 (talk · contribs) ( http://en.wikipedia.org/w/index.php?title=RAID&diff=523846804&oldid=523363466 and http://en.wikipedia.org/w/index.php?title=RAID&diff=523846913&oldid=523846804 )due to the fact they removed the entity of the Standard Raids section, removed part of the cite in the nested/hybrid section, and added no content. I'm going to assume this is either vandalism or accidental, though the IP does have other changes elsewhere that look less suspicious. Anything needed other than undoing the edit? Nazzy (talk) 15:58, 19 November 2012 (UTC)

Nope! If an edit seems accidental or otherwise incoherent, and is not explained in the edit summary (the editor you mention didn't leave edit summaries), simply undoing it is the best solution. On a similar note, always providing edit summaries helps others understand your edits. – voidxor ^{(talk | contrib)} 08:07, 19 January 2013 (UTC)

reliability terms mistake

in the section "reliability terms" it says: "System failure is defined as loss of data and its rate will depend on the type of RAID. For RAID 0 this is equal to the logical failure rate, as there is no redundancy." however wouldn't the faliure rate be higher, asuming each drive in the array has a chance of faliure and the data is spread across more than one drive? ~patrick

Claim that RAID 3 is theoretical and not used in practice is incorrect.

The article claims RAID 3 is a 'theoretical' RAID level and 'not used in practice.' This is incorrect, EMC Clariion and VNX support a RAID 3 option. — Preceding unsigned comment added by 98.229.192.30 (talk) 21:28, 14 December 2012 (UTC)

Yes true, there do appear to be several older implementations which used RAID 3- the article text has now been changed to say that RAID 3 is not widely used in practice, with a link to the BSD Unix implementation. I believe that is an accurate assessment of the current usage- is the RAID 3 option still supported in the product lines examples above? It would be good to find a reference giving estimated usage of these RAID levels in contemporary products.

121.45.193.118 (talk) 12:09, 20 December 2012 (UTC)

You can see the RAID 3 reference, as well as 0, 1, 1/0, 5, and 5 in the current (1/7/2013) datasheet for EMC VNX on their website. http://www.emc.com/collateral/hardware/data-sheets/h8520-vnx-family-ds.pdf — Preceding unsigned comment added by 168.159.213.60 (talk) 20:02, 7 January 2013 (UTC)

Duplicate sentence

The sentence "a single drive failure results in reduced performance of the entire array until the failed drive has been replaced and the associated data rebuilt" appears twice in the description of RAID 5. Somebody should fix it. 173.34.179.126 (talk) 14:19, 22 December 2012 (UTC)

Done. 121.45.193.118 (talk) 22:09, 22 December 2012 (UTC)

Various improvements - feedback please.

I've just made a few edits to improve clarity.

I'm looking for constructive criticism regarding the following ones:

(and feel free to make them for me.

CONFUSING:

"Background scrubbing can be used to detect and recover from UREs (which are latent and invisibly compensated for dynamically by the RAID array) as a background process, by reconstruction from the redundant RAID data and then re-writing and re-mapping to a new sector; and so reduce the risk of double-failures to the RAID system[42][43] (see Data scrubbing above)."

Idea:

Add a subheading to this section and the one above what's CONFUSING

and

= Mitigations

REWORD THUS:

Double....

Background data scrubbing is a RAID feature that [mitigates the problem|attempts to address the issue] by having a background process read drive blocks when a drive is idle and whenever a URE occurs, using the redundant RAID data to reconstruct, re-write and re-map the logical block to a new spare block, and so...

or perhaps

Background data scrubbing is a RAID feature that [mitigates the problem|attempts to address the issue] by having a background process read drive sectors when a drive is idle and whenever a URE occurs, using the redundant RAID data to reconstruct, re-write and re-map the logical sector to a new spare sector, and so... Where the read triggeres a Recoverable Read Error, the drive itself reconstruct, re-write and re-map the logical sector to a new spare sector...

Section on Atomicity: Wow, this is confusingly written. Perhaps it should kick off with the simple statement, like "Databases are designed to maintain data consistency despite the non-atomicity of the write process of the disk drives on which they normally store data, even when there is unexpected power loss." If I'm not mistaken, either disk drives can't perform atomic write processes, period, or ones that can are rare enough to merit little more than a parenthetical.

Write case reliability:

P(aragraph)3 doesn't mesh with P1 and P2. In fact all 3 are about write-back, but only P3 calls it that. Merge 'em.

Hardware Labeling:

Some systems have a feature intended to reduce operator error and facilitate drive failure management by having an LED by a failed drive indicate that it is a drive that has failed.

History:

REMOVE:With S/38 checksum, when a disk failed, the system stopped and was powered off. Under maintenance, the bad disk was replaced and the new disk was fully recovered using RAID parity bits. While checksum had 10%-30% overhead and was not concurrent recovery, non-concurrent recovery was still a far better solution than a reload of the entire system. With 30% overhead and the then high expense of extra disk, few customers implemented checksum.[citation needed]

doesn't make sense.

It's so confusingly written I don't know what it's trying to say or how to fix it.

--Elvey (talk) 11:42, 30 December 2012 (UTC)

RAID 10 compared to RAID 5 section moved here for improvement

The section ==Mirroring versus parity RAID levels in relational databases== is very problematic- e.g. the claim that "Given the rare nature of drive failures in general, and the exceedingly low probability of multiple concurrent drive failures occurring within the same RAID, the choice of RAID 5 over RAID 10 often comes down to the preference of the storage administrator" is incorrect-- UREs are extremely likely to happen with large disks and thus RAID 5 is not recommended for large databases by the major storage manufacturers (as noted in the main article). The references given are to a non-authoritative web site and do not support the claims in any case. A well-referenced section on this topic could be useful, but the current section is misleading to users of RAID. The current text is copied below for improvement before possibly returning to the main article. 121.45.213.224 (talk) 06:54, 28 January 2013 (UTC)

Mirroring versus parity RAID levels in relational databases

A common opinion (and one which serves to illustrate the dynamics of proper RAID deployment) is that RAID 10 (a non-parity, mirrored RAID) is inherently better for relational databases than RAID 5, because RAID 5 requires the recalculation and redistribution of parity data on a per-write basis.

There are, however, other considerations which must be taken into account other than simply those regarding performance. RAID 5 and other non-mirror-based arrays offer a lower degree of resiliency than RAID 10 by virtue of RAID 10's mirroring strategy. In a RAID 10, I/O can continue even in spite of multiple drive failures. By comparison, in a RAID 5 array, any failure involving more than one drive renders the array itself unusable by virtue of parity recalculation being impossible to perform. Thus, RAID 10 is frequently favored because it provides the lowest level of risk.

Modern SAN design largely masks any performance hit while a RAID is in a degraded state, by virtue of being able to perform rebuild operations both in-band or out-of-band with respect to existing I/O traffic. Given the rare nature of drive failures in general, and the exceedingly low probability of multiple concurrent drive failures occurring within the same RAID, the choice of RAID 5 over RAID 10 often comes down to the preference of the storage administrator, particularly when weighed against other factors such as cost, throughput requirements, and physical spindle availability.

RAID 10 space efficiency calculations seems off

It seems that RAID 10 and RAID 1 should have the same space efficiency formula, namely 50% since they both only use mirroring to tolerate single drive failures. — Preceding unsigned comment added by 99.245.3.15 (talk) 19:40, 1 February 2013 (UTC)