Talk:Nested RAID levels

== Comparison table: use 'strips' instead of 'stripes' The use of the term 'stripe' in the comparison table does not seem in line with convention. The term 'stripe' is commonly used to refer to a collection of data 'strips' and their parity 'strip'. Each strip (data or parity) is located on an individual drive; e.g. for a RAID 5 array of 4 drives there would be 3 data strips and 1 parity strip per stripe. Strips are typically sized in kilobytes and hence there are millions of stripes in a typical RAID array. To correct the comparison table, I have replaced the word 'stripe' by 'strips/stripe'. — Preceding unsigned comment added by 77.163.241.75 (talk) 09:29, 6 January 2021 (UTC)

Ammount of disks that can fail when using RAID1+0

I doubt this section:

All but one drive from each RAID 1 set could fail without damaging the data. However, if the failed drive is not replaced, the single working hard drive in the set then becomes a single point of failure for the entire array. If that single hard drive then fails, all data stored in the entire array is lost. As is the case with RAID 0+1, if a failed drive is not replaced in a RAID 10 configuration then a single uncorrectable media error occurring on the mirrored hard drive would result in data loss. Some RAID 10 vendors address this problem by supporting a "hot spare" drive, which automatically replaces and rebuilds a failed drive in the array.

Give the example picture; when A1R and A2R would fail, then A1L and A2L would still be able to function. The RAID is in a serious degraded state, and any of the disks would be a SPOF right now, but it would make the failure of 2 disks possible.

However, if A1L and A1R would both failt simultaneously, then you would only be able to loose 1 disk before data lose will occure.

Eagle Creek

- Hi Eagle Creek; nothing you mention is in conflict with the information in the section. You say that a single uncorrectable media error would result in data loss if it occurs on a single remaining mirror, and that this can be addressed by using a 'hot spare', however this is not entirely correct. The use of a 'hot spare' is not to prevent against such data loss, since an unrecoverable media error occurs with equal probability when restoring to a newly installed drive or to a hot spare. A hot spare can only prevent data loss due to urecoverable errors that would have occurred before you are manually able to get to the array and replace the broken drive while the last mirror remains functioning. If you are able to reconstruct a mirror manually whenever one drive fails, I don't believe a 'hot spare' provides any benefit. Most importantly, while RAID provides some protection against drive failure, it's not a backup.

I think that the RAID 50 example is wrong

It says: “Below is an example where three collections of 240 GB RAID 5s are striped together to make 720 GB of total storage space”, but the image shows 120 GB drives. Also, as every RAID 5 losses 1 disk of capacity, it would add to 240 GB * 2 drives per RAID 5 array * 3 RAID 5 collections = 1440 GB. With 120 GB drives, it does add ok to 720 GB. Norfindel (talk)

Comparison table

I fudged around a lot with the table. The most dubious edit I did was adding the RAID 1+6 row, which is only dubious because it's never found "in real life".

Another thing I did was divide the fault tolerance column into min-max values, which makes sense. If you want to go back to single column, then keep only the min column - the max column (which the former single-column content talked about) is basically for optimists, not sysops. ;) 130.239.26.87 (talk) 13:53, 13 September 2018 (UTC)

---

• I am going to remove the `Failure rate' column, as there is presently no data present. If someone wishes to add such data, they may revert the edit and add the data.
• Since the only information in the `Read performance' and `Write performance' columns- and the data which is present (for NESTED RAID LEVEL 1+0/10) is incompletely represented in the chart (requiring a footnote), I am removing those columns as well. To retain the performance data for RAID 10, I will move the data from the chart to the footnote and move the location on the inline footnote anchor to the first column.
• I am removing the footnote explaining the definition of variable `m' used for capacity calculation for certain levels, in place on variable `n' from a footnote, to the bulleted point above which describes how `n' is calculated (a seemingly more fit place- as the two variables are directly related).

\*More information regarding this section would be highly useful. I would add my knowledge, but unfortunately, I do not have time to hunt down the references, and do not want to add unreferenced material.

--108.46.206.82 (talk) 13:30, 31 May 2019 (UTC)

Fixing Citation References

I hope I did not step on anyone's toes with edits to this article but I found the location of where some of the citations were located as a bit odd and hard to comprehend. There were three citations right smack in the middle of the sentence in the RAID 10 (RAID 1+0) section when talking about performance. I understand what the last editor was trying to do since there were three different concepts all strung throughout the one sentence. I moved them to where I thought they made the most logical sense. I moved the Intel Rapid Storage citation to after RAID 10 since that is what it is addressing. I moved the IBM RAID controller citation to after the sentence references better throughoutput and latency than other RAID levels. I moved the PC Guide reference about comparing all Nested and regular RAID levels to the end of the sentence where it makes the exception about RAID 0 providing the best throughput but worse latency. If anyone has any issues with how I ordered / changed the citations feel free to undo them or engage with me here about how they should be. Kc7txm (talk) 22:58, 28 May 2019 (UTC)