Talk:Standard RAID levels

Statistically independent

The article said due to the same environment the chance of failure for discs in a RAID wouldn't be statistically independent. That's not true, because though both will suffer the same impact on failure rate, the chance of a single disc failing is still independent from another one failing.

Only if failure of one disc would increase the chance of failure in the other, that would make it statistically dependent.

For example in standard condition chance of failure would be 5%, and in damp environment it'd be 10%. Then the chance of both discs failing would be 0,25% and 1%. --Bur (talk) 14:30, 3 September 2008 (UTC)

Actually the article mentions environmental conditions as one possible shared cause of failure, and lists a reference for it. Other things that were mentioned, and which you deleted, are common origin of the disks, and so forth. I believe deleting this paragraph was a mistake.

Hpa (talk) 23:32, 3 September 2008 (UTC)

RAID-0 performance

The statement about performance of Raid0 in games yielding negligible benefits is incorrect, games regularly access large chunks of data not just during level loads but also during gameplay, Oblivion is a perfect example, the difference between loading times for new area content between Raid0 and non Raid would most likely be more than 20 seconds each time, meaning it's essentially the difference of smooth uninterrupted gaming compared to sitting and waiting for content to load, hardly "minimal". —Preceding unsigned comment added by 203.214.17.51 (talk) 05:19, 8 September 2007 (UTC)

Get more RAM. One point that seems to come up pretty frequently in these types of discussions is that RAID-0 boosts overall performance when there is a virtual memory bottleneck. However, you can solve this problem with RAM, which is cheaper, more robust, and easier to setup. Afterwards, the virtual memory bottleneck goes away and RAID-0 once again has no measurable effect. Of course, if you have reliable sources to the contrary, share them. Ham Pastrami 09:36, 8 September 2007 (UTC)

The 4th reference from the page is obsolete in my opinion. It's 5 years old and since then many things happened in the industry and RAID-0 is still a very good choice - performance wise (eg. when high density platter harddrives / solid state disks with SATA-II interface are used) —Preceding unsigned comment added by Nashu2k (talk • contribs) 21:19, 15 June 2009 (UTC)

Introduction

Admittedly, this page is likely to be accessed only be those with some prior knowledge of the subject, but even so, the page ought to begin with a more substantial introduction to orient the reader more clearly to the subject, in the manner of an encyclopedia entry. R.braithwaite 20:47, 30 December 2006 (UTC)

Granted this article is very lacking in an introduction, but doesn't RAID cover the basics to what RAID is? Cburnett 06:23, 31 December 2006 (UTC)

The article was split off in the first place because the original article was 213213246513 kb long! Sheesh. The whole point was to cut them down, not make each one as long as the last. Summarizing the section from the orig. article should be adequate.// 3R1C 15:20, 25 January 2007 (UTC)

I whole-heartedly disagree. Each RAID level could easily be made into its own article and should be encouraged to do so. Each one made into its own article can then be summarized in a paragraph on this page with a {{main}} link to the article. Cburnett 15:35, 25 January 2007 (UTC)

I've added a draft for the RAID 4 missing section. Hernandes 21:14, 23 January 2007 (UTC)

technical errors

The RAID-0 section has some errors such as saying that the seek time will be divided by the number of drives if you're reading less than the stripe size. The claim that "reliability of a given RAID 0 set is equal to the average reliability of each disk divided by the number of disks in the set" is also suspect since the reliability cannot possibly be better than the least reliable drive in the array. It also is discussing an arbitrary array and suddenly starts assuming two disks. It sort of looks like someone who didn't understand the existing text added some sentences at the end of a previously good paragraph.

Mixing RAID modes

Is it possible to mix RAID modes? I remember reading about RAID 1+0. Is it possible to use RAID 0 with any other mode? It seems like you'd have twice as many drives to support the addition of RAID 0. (So RAID 6+0 would need a minimum of eight drives?) --72.202.150.92 05:54, 30 January 2007 (UTC)

Absolutely. See nested RAID levels. Cburnett 06:01, 30 January 2007 (UTC)

Typo in the RAID-5 section?

In the RAID-5 section, it is currently written:

In the example above, a read request for block "A1" would be serviced by disk 1. A simultaneous read request for block B1 would have to wait, but a read request for B2 could be serviced concurrently

Looking at the figure, should it instead say "disk 0"? I hesitate to change it, because I actually don't know a lot about RAID yet.--Skoch3 02:58, 1 February 2007 (UTC)

Also, same with RAID-4 section.--Skoch3 03:04, 1 February 2007 (UTC)

Yes and corrected. Cburnett 03:09, 1 February 2007 (UTC)

Great, Thank you! Am I supposed to delete this section now? Not sure of the custom. --Skoch3 07:56, 3 February 2007 (UTC)

RAID-6 Resource

I personally found the description of RAID-6 presented here to be rather lacking on how the double parity works. A PDF at http://www.infortrend.com/3_support/pdf/RAID6_White%20Paper.pdf seems to go into a more detailed explanation, but I'm not informed enough to add it here. Maybe someone with more knowledge would be able to help? If nothing else, it is a nice resource for others.Quad341 20:18, 27 February 2007 (UTC)

left-symmetric and left-asymmetric

While setting up a RAID system recently, I wondered whether I should choose the "left-symmetric" vs. "left-asymmetric" option.

A quick Google led me to "Left-symmetric offers the maximum performance on typical disks with rotating platters." [1] which answered my immediate question, but didn't really explain what it is. Later I found an illustration that seems to explain the difference: "Left-symmetric and left-asymmetric algorithm are demonstrated in Figures" [2].

Using our current Wikipedia notation, "left-symmetric" and "left-asymmetric" look like this:

left-asymmetric:

 A1 A2 A3 Ap
 B1 B2 Bp B3
 C1 Cp C2 C3
 Dp D1 D2 D3
 E1 E2 E3 Ep

left-symmetric:

 A1 A2 A3 Ap
 B2 B3 Bp B1
 C3 Cp C1 C2
 Dp D1 D2 D3
 E1 E2 E3 Ep

If I understand correctly, our RAID 5 illustration currently shows the "left-asymmetric" variant, which (if I understand correctly) no one really uses -- everyone uses "left-symmetric" because of its greater performance.

(By inspection, I can see that "left-symmetric" has better performance, because if you read any 4 consecutive blocks -- for example, if you read A2, A3, B1, B2 -- left-symmetric can read them all simultaneously from all 4 disks, while left-asymmetric maps 2 of them to the same disk -- in this case, A2 and B2 -- so the read from B2 must wait until A2 is done).

Could someone confirm for me that everyone that uses RAID5 really uses "left-symmetric"? (And if not, why would anyone use anything else?)

Could someone update the RAID-5 section to illustrate the type of RAID5 that, in practice, everyone uses?

--68.0.120.35 01:29, 11 March 2007 (UTC)

RAID 6 explanation

The figure used in the explanation of RAID 6 seems to be very confusing as it mentions two parity blocks per row, although the second syndrome is definitely not parity, as explained in the HPA's paper cited below.

MJ 18:12, 29 May 2007 (UTC)

Some of the content in the RAID 6 section is copied verbatim from the following:

http://support.dell.com/support/edocs/storage/RAID/PERC6ir/en/HTML/en/chapter1.htm#wp1053533 —Preceding unsigned comment added by 97.81.31.51 (talk) 18:22, 13 July 2008 (UTC)

RAID 5 Performance

The article says that raid 5 performance is nearly as good as a raid-0 array with the same number of disks. This isn't quite accurate.

In theory at least, a raid 5 array should be the same performance as a 1-disk smaller raid-0 array (works out at the same amount of usable storage). Using a 4-disk raid 5 array as an example, every 4th block on the disk would be a parity block, which would need to be skipped when reading. Skipping a block should take the same amount of time as reading it, after all the disk still has to spin the same amount. This means that each disk only spends 3/4 of it's time reading. Multiply this across all 4 disks (parallel reading), it works out at 3x single disk speed, or the same as a 3-disk raid-0 set.

If anyone can verify this it should be added to the page.

85.133.27.147 13:33, 15 June 2007 (UTC)

You are 100% right about reads but RAID5 always had a lacking performance of writes. When you are writing a small amount of data (less than a full stripe) RAID5 has to: read the old data blocks, calculate parity, write new data blocks and the new parity block. In the disk arrays I've tested (EMC Cxx, IBM DS4xxx, Sun FLX) such writes have practical 50% to 65% performance impact in terms of writes/second. Full stripe writes are neither theoretically or practically affected. --Kubanczyk 06:23, 25 June 2007 (UTC)

This section needs to be made consistent with the main RAID article. There, the performance problems of RAID5 is debunked as "myth". Are there really no data available on this? Ketil (talk) 08:28, 9 February 2011 (UTC)

Origin of watercooler raid.jpg?

Does anyone know the copyright status of this image? It's an easy to understand illustration of RAID levels, and might make a great addition to the article, possibly in a redone/computer generated format. Is it accurate too? http://www.edvt.net.nyud.net:8080/Pictures/raid.jpg Family Guy Guy (talk) 23:05, 14 February 2008 (UTC)

RAID 1 vs 0

The section on RAID 1 seems to imply that there is a data access performance improvement for RAID 1 configuration. I just built a new computer and configured RAID 0 believing that would yield the best performance (albiet with some degradation in reliability). Data access seems to be very fast, but would RAID 1 have been just as fast, with higher reliability? From the data published here, it seems like the best approach would be to add a third drive and move to RAID 5. Is that correct?

Dadman 5 (talk) 21:03, 22 April 2008 (UTC)

0 & 1 provide no data integrity.

5 does parity so you can at least detect data corruption (no requisite that periodic integrity checks actually be done though), but 5 comes with a computational cost (particularly for software raid).

What is "correct" depends on your goal. You speak of performance and reliability which are, [very] generally speaking, exclusive. Wikipedia is also not a help forum so I suggest finding a forum somewhere... Cburnett (talk) 00:01, 23 April 2008 (UTC)

Are you sure? Level 1 and 5 provide similar (i.e. no) integrity: they can both detect data corruption, but neither will point out where the corruption took place, or what the correct data should be. RAID 6 can do this, but data corruption is not high on anyone's agenda yet. Rightfully, disk failure has been the main concern, as losing a disk has much direr consequences than losing a bit. It would be easy and desirable though to have raid 6 solutions that periodically run integrity checks and fix corrupt data. See an informal discussion on so-called bit-rot here. This extra level of protection will make raid 6 more and more popular I hope. 116.89.224.136 (talk) 07:35, 3 October 2008 (UTC)

RAID 1 failure rate

Both disks failing within 3 years is not equivalent to data loss. For data loss, both disks must fail *at the same time*. Otherwise, the failing disk can be replaced and the RAID restored.

In summary, to calculate the probability of data loss, one has to make some other assumptions:

• Time to replace a failed disk and restore the RAID: 24 hours
• Failure within 3 years: 5% (uniform)
• Disk failure independency

Giving:

• P(overlap) = 2 / (365*3)
• P(data loss) = 5% * 5% * p(overlap) = 0,0005%

For simplification, I considered that the prob of a disk failing twice is zero. —Preceding unsigned comment added by 85.62.99.137 (talk) 13:48, 25 February 2009 (UTC)

RAID 0 statistics

There is unfortunately no evidence provided to suggest that the lifespan of a disk shortens simply because it is in an array as the article would have you believe. The formula supplied suggests that with just two disks the chance of failure nearly doubles! Where does this pearl of wisdom come from? MTTF is MEAN time to failure - i.e. average - and has never espoused to be a specific value.

Consider this - MTTF for a two disk array should in fact be double based on the work done by the drive - the drives should each read and write HALF of what a double capacity single disk would have to do, since the work the drive does is split. At worst the reliability of the RAID 0 drives will the average of their original respective reliability, since MTTF is very specifically involved with averages. There is absolutely no support at all for the baloney theorem proposed, and it's curious but not surprising that this article has been contested the way it has.

RAID controller

Does RAID must require a RAID controller, I know BIOS support is a must, but unsure about the controller part. --Ramu50 (talk) 04:18, 11 July 2008 (UTC)

RAID 5

How many additional drives are need to implement RAID 5 on the system, if the implement method of RAID requires an operating system be in place on Drive C: Kagemaru the Ninja of the Shadows (talk) 03:12, 6 December 2008 (UTC)--Kagemaru the Ninja of the Shadows (talk) 03:12, 6 December 2008 (UTC)

Source problems

I've done some reworking and cleanup of the section on "RAID 5 disk failure rate" because, while cleaning up other issues like letter-case and unnecessarily long sentences crammed with technical details, I discovered significant problems with several sources which seem to be endemic to this article (and indeed to many Wikipedia articles). I've fixed a few, but there remains much else to be done. Besides reformatting some of the sources in order to be able to see the prose well enough to clarify it:

• I removed most of the latter part of the second paragraph (discussing "the relatively stagnant unrecoverable read-error rate") because it was hard to understand the point trying to be made without reading all the sources. Those, in turn, left something to be desired: two blogs and two anonymous discussion-group posting. I left the first two in, as they may be salvageable or replaceable. But discussion group postings are nothing but anonymous opinions and assertions and cannot be used as references. (See WP:RS.) In place of the second portion, I rewrote what I believe to be the point of that half-paragraph, and stuck {{fact}} tags on my totally unsourced assertions. (After all, officially I'm no more reliable that any other unpublished writer.)

• I rewrote the text on STEC's Zeus SSDs because it talked about transactional performance in a section on failure rates. In fact, I completely changed the promotional sense of the info on STEC's Zeus (based on the corrected source for that info) because, ironically, much faster performance should lead to much smaller MTBF (at the same error rate, which the source suggests is the case). More fact-tags here as well. I'll leave the question of comparing sector failures (STEC's specs) to bit-read failures (Western Digital's specs) for someone else to write (backed by reliable, independent sources). I suspect the answer isn't as simple as a mere unit conversion.

• Actually, now that I think about it, I didn't notice any of the comparisons made in our article between HDs and SSDs (related to RAID-5 failure rates) in the sources, only some single-drive performance comparisons from STEC. (I wasn't as thorough on this, so I could be wrong.) It's not enough to source the raw data; we need to source the conclusions drawn (including mine!) or delete it an unsourced original research.

• I removed a comment stuck on one sub-heading:

===RAID 5 performance=== <!------[RAID] links here-------->

I couldn't figure out what this was supposed to mean. First of all, [RAID] is not a link. If they meant that [[#RAID]] (an internal link) elsewhere in the article is linked to this heading, they're wrong – it links to the heading/anchor "RAID", which doesn't exist. (I didn't find any such link anyway.) If they meant that one or more other articles were linking to this section (the usual rationale for such a comment), they should have made this clearer, so editors here would reconsider any attempt to change the heading. If they meant to insert another link to this heading (using a <span id> or <div id>), they forget to add the tag (or someone deleted it without deleting the comment). In any case, an HTML anchor for "RAID" is a bad idea because the entire article is about "RAID", not just this section. Any link to this section can use regular wiki syntax: [[Standard RAID levels#RAID 5 performance]].

I also did some checking on references and cleaning them up, since bare links and external links labeled only with a rephrasing of the content are almost guaranteed to fail eventually. (Always include the title of the content, verbatim, as well as the work it belongs to, the website name or publisher, the author, and the date. Many of these are missing from web pages, but putting in as much of this as you can will help others (maybe even yourself) later when some of these links break.) But I've just run out of time after all the other research, so I'll have to leave it to other editors. Feel free to post to my talk page if you have any questions. ~ Jeff Q (talk) 01:40, 28 June 2009 (UTC)

Arggh! I just noticed that the section on RAID-5 performance has significant overlap with "failure rate", too! ~ Jeff Q (talk) 01:41, 28 June 2009 (UTC)

Raid 5 Gotchas

Now that disks are relatively large (1TB is not uncommon), there exists a substantial chance that while an array is being rebuilt, at least one single-byte error will occur on one of the remaining disks. The raid controller will then throw the 2nd disk out of the array. As a result, instead of silently corrupting a single byte (which we probably wouldn't even notice in most cases), the array will totally self-destruct.

This happened to me; it's especially problematic with a group of disks all from the same batch (as when one dies, the rest are potentially failing, and doing a complete read may trigger an error).

My suggestion is to use only Raid 1 or Raid 6; Raid 5 is now too risky for large arrays. For more, see eg: http://www.maximumpc.com/article/news/raid5_may_soon_be_obsolete —Preceding unsigned comment added by 87.194.171.29 (talk) 15:33, 29 July 2009 (UTC)

Error in RAID 5 calculation?

I'm really not an expert in RAID, but... The RAID 5 section states:

RAID 1 or RAID 1+0, which yield redundancy, give only s / 2 storage capacity, where s is the sum of the capacities of n drives used. In RAID 5, the yield is s x (n - 1).

The first part looks incorrect to me. If I understand RAID 1 right, it's the size of the smallest unit that should be considered, not the total size; that statement assumes equal-size disks. Instead, it should probably be something like

... give only s storage capacity, where s is the capacity of the smallest disk (or whatever word is right, since it also discusses RAID 1+0 - maybe array would be better than disk?)

Then the s formula of RAID 1 and the s * (n-1) formula of RAID 5 are consistent: with n = 2, then RAID 1 and RAID 5 have the same capacities.

Did I get all this right? (I didn't make the change in the text because I wanted someone else to confirm that I'm not crazy :P) --67.22.228.34 (talk) 16:10, 22 September 2009 (UTC)

I think there's an error in the calculation for capacity for RAID 5 in the initial summary. If s is the sum of the capacities, then four 1 TB drives will have s=4. Going by the calculation, the yield will be 4 *(4-1) = 12 TB! It's not s * (n-1) but (capacity of single disk) * (n-1). Since I'm not familiar with RAID very much, I'm not yet making a change. But I'm still fairly certain that I have it right. Opinions anyone? Bhagwad (talk) 16:25, 26 October 2009 (UTC)

I've made the changes... Bhagwad (talk) 16:29, 27 October 2009 (UTC)

Good change. --Enric Naval (talk) 01:24, 30 October 2009 (UTC)

Outdated Information

According to the page, "JEDEC is preparing to set standards in 2009 for measuring UBER (uncorrectable bit error rates) and "raw" bit error rates (error rates before ECC, error correction code)". What was the result? —Shanesan (contribs) (Talk) 20:43, 21 April 2011 (UTC)