Talk:Standard RAID levels/Archive 1

Archive 1

Archive 2

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)

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)

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)

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)

The infortrend link above seems broken; but this seems like a good resource for the dual parity concept: http://kernel.org/pub/linux/kernel/people/hpa/raid6.pdf. — Preceding unsigned comment added by 171.66.169.117 (talk) 01:06, 25 May 2012 (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)

I would not be so fast with this conclusion since the problem that writes do need potential multiple reads still exists, however it is somewhat masked by the use of cache to avoid reading blocks for parity generation. In a system with no or just limited cache, write performance is poor. Depending on the algorithm used to calculate the parity, performance can be worse the more disks are used. Even so it is potentially possible to recalculate the parity block based on the changed block and the previous parity block, and in such an action only having to read two and write two blocks, the operation of reading and writing the same block usually requires a full spin of the drive more for a commit than on a regular single drive. So from a average of at least .5 spins to write a block we get to 1.5 spins basically tripling write access time! In practical applications one can eliminate this problem partially by using large amounts of cache (Which is why Kubanczyk is not seeing any performance issues in the platfroms he mentions!) Write-Back cache (which always should go with a battery backup for the cache) will further help to eliminate these problems! --Fgwaller (talk) 04:56, 12 May 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 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)

There is a problem with how raid 5 failure is described. in Section "RAID 5 usable size" it is stated 'One caveat is that unlike RAID 1, as the number of disks in an array increases, the chance of data loss due to multiple drive failures is decreased. This is because there is a reduced ratio of "losable" drives (the number of drives which may fail before data is lost) to total drives.' This in fact is wrong. The chance of data loss due to multiple drive failures is actually increased as you can only have 1 drive fail in a set (until the set is rebuilt) before the set fails. Hence a larger number of drives results in a larger chance of more than one drive failing before the set is rebuilt. Incidentally this also means there is an increase in potential failure of the set as the element size increases too. The statement containing 'ratio of "losable" drives' will also need to be rewritten I believe. 58.6.5.175 (talk) 00:15, 23 November 2011 (UTC) David Godfrey

It already says precisely what you have said. If there is a problem it is one of comprehension. Crispmuncher (talk) 13:58, 23 November 2011 (UTC).

One version says "increased" and the other "decreassed", so how come you see these as saying the same thing Crispmuncher? Of course the problem is one of comprehension, however the issue is how to make that which is communicated clearer LookingGlass (talk) 14:15, 13 May 2012 (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)

Orthography.

I don't know much about RAID levels so I came here to learn. However, it seems that it needs a little bit of work on the grammatical side. I'm not an expert so I'd rather leave it for someone who knows more about the subject. I just wanted to point it out. — Preceding unsigned comment added by 58.164.218.183 (talk) 05:39, 23 June 2011 (UTC)

RAID 5 latency formula

In the section on RAID-5 performance a formula is given to calculate the rotational latency of a raid-5 write request in terms of number of disks in the set. I added a "citation needed" since the formula is not commonly known (and conflicts with others I have seen). What is the origin of this formula? Can the author post the derivation? — Preceding unsigned comment added by 128.221.197.57 (talk) 12:46, 12 September 2011 (UTC)

The previous formula (1-2^-n) was incorrect: it calculates the relative frequency at which none of the platters require more than half a revolution, not the expectation value (mean) of the number of revolutions. I have corrected the formula, and added the formula for the median which is also quite informative. I don't have any textbooks handy so I couldn't find a reference, but these formulae _are_ well known, and easy to verify by numerical simulation even if you don't understand the probability & statistics. So, I don't think this formula really needs a citation—but it certainly wouldn't hurt if somebody comes across one. (It should be a textbook though: the incorrect formula has been on Wikipedia for some time now. That misinformation has probably propagated.) I'll keep an eye out for a reliable source. Gerweck (talk) 03:25, 23 April 2012 (UTC)

The N/(N+1) fraction you present is only correct for full stripe writes, which are uncommon in most computing systems, particularly so in OLTP workloads.

For the most common case, non-full stripe writes, the formula you present is incorrect. The N/(N+1) fraction is the latency for an arbitrary RAID level where the ganged write size is N, not just RAID-5. For instance, in RAID-5 you must update 2 physical disks for l logical write, N here is 2. Thus the average latency is: 2/(2+1) or 2/3 of a revolution. For RAID-6 the ganged write size is 3, as 3 disks must be updated for each logical write and so the average latency is 3/(3+1) or 3/4. This is the reason that an average RAID-6 write is always slower than its RAID-5 counterpart, even on an idle array. R6 is slower (longer) by 3/4-2/3 or 1/12 of a revolution, about 0.67 ms on a 7200 RPM drive. In either there is absolutely no dependence on the number of disks in the array, it is on the ganged write size (1 for RAID 0 and single disks, 2 for RAID-4, RAID-5, and RAID-1, 3 for RAID-6).

The exception is the very uncommon RAID-3 where N is the disk count in the array, because in an R3 write, each disk must always be updated, i.e. all writes are full stripe writes. Non-standard mirroring (RAID-1, e.g. in OPENVMS) allowing more than 2 disks is also an exception for the same reason and in the same way, i.e. N is the number of mirrors. — Preceding unsigned comment added by 168.159.213.53 (talk) 19:10, 14 June 2013 (UTC)

Striping /RAID 0 failure

This section has been unsourced since March 2010. Anyone have a source? - CompliantDrone (talk) 23:54, 19 September 2011 (UTC)

Propose moving RAID 6/Double parity here from /wiki/Non-standard_RAID_levels

RAID 6 has become very common. Propose moving it here from Non-standard_RAID_levels. Thoughts? Ktoth04 (talk) 21:29, 8 September 2012 (UTC)

Image keys needed

Somebody desperately needs to add a sentence or three to each "RAID x" section, explaining what the "A1", "B3", etc, in each of the images mean exactly. Apparently the meaning is slightly different for each RAID level, but that's not obvious. Currently there are no explanations of the letter+number image labels anywhere on the page. 99.102.75.166 (talk) 19:20, 22 April 2013 (UTC)

Changing the RAID 0 and RAID 1 diagrams

I agree with a prior post that the numbering scheme on the diagrams varies subtly. I'm willing to fix this (and the textual references to the diagrams), but am a bit worried by the fact that many other docs point to the same diagrams. What is the best way to undertake the fix? Upload new files with different names? What happens to all the translated pages?

Thanks,

Alan G. Yoder, Ph.D. 23:13, 22 April 2013 (UTC) — Preceding unsigned comment added by Alanyoder (talk • contribs)