This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 | Archive 3 | Archive 4 | Archive 5 |
How about a new page (with appropriate disambiguation) for memory RAID? Not much information out there on it, but it is available and fairly easy to configure on, for instance, a Dell PowerEdge:
http://support.dell.com/support/edocs/systems/pe6850/en/it/h2147c60.htm#wp1081442
(Scroll down to Memory RAID Support.)
The contingency being: is R.A.I.D. (D now standing for DIMM, just to make matters confusing) the correct acronym?
-- 64.139.53.163 19:11, 2 March 2006 (UTC)
I don't get the sentence no
[quote] "Currently, most (all?) of the other cheap RAID BIOS products only allow one disk to participate in a single array." [/quote]
Surely that should be the other way round. no? allow a disk to participate in only a single array?
If I have
A,B,C disks A,B are for data, C for parity something like RAID 4
A,B are full and so is C I add a new buffer D,E I do not wish to "resize A,B"
Can I simply not start writing to D and simply modify the parity on C to do C= parity A,B,D, E ? if parity is XOR then simply Xorin C with new data on D xor E should suffice... (you may have to maintain a pointer as to how much on C is old parity and how much is new etc as data comes on D,E)
In other words one may not need to "restripe" everything? Is this done somewhere? It would imply treating "disks added" as bunch across which there is a stripe.
-alokdube@hotpop.com
>>>>> With present CPU speeds, software RAID can be faster than hardware RAID, though at the cost of using CPU power which might be best used for other tasks
This is totally unsubstantiated. I am unaware of a hardware raid solution that doesn't operate at the maximum hardware I/O speeds. Provide a reference to substantiate this claim.
See: http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/custom-guide/s1-raid-approaches.html
"With today's fast CPUs, Software RAID performance can excel against Hardware RAID."
>>>>>
--> wouldnt matter would it? as long as one can "plug off the BOD and put it elsewhere" and not worry, whether it is software or hardware it should not matter. However in both cases "not restriping" is a benefit.
This writing is definitely NOT up to the quality required to post to the article (I am extremely tired right now, which does not help my writing ability); could someone please proofread and post to the main article (or at least provide some suggestions on reworking it when I'm more awake)? Thanks! 70.92.160.23 05:24, 24 March 2006 (UTC)
Infrant Technologies's X-RAID is a RAID method that allows for the dynamic expansion of existing disk volumes without losing any data already present on the volume. It currently is limited to a maximum of 4 drives per RAID volume, but certain OEM products utilising custom Infrant boards have room for up to 7 drives (although the X-RAID mode will still only work with a maximum of 4 drives per volume, work is being done to increase the maximum number of drives per volume). X-RAID utilises a proprietary extension to regular Linux volume management and runs using the Ext3 filesystem. This means that X-RAID volumes can be mounted by a standard Linux installation, even when connected to a non-Infrant device. When two drives are installed in an X-RAID device, the X-RAID system runs in a redundant RAID 1 mode; with three or more drives, the device runs in a mode similar to RAID 5. X-RAID allows for the automatic expansion of volumes by replacing all disks in a volume with larger-sized disks. Once all disks are replaced, the volume automatically expands to fill the newly available space. It also allows for starting with only one disk and adding disks on-the-fly without losing any of the data already existing on the volume. Technical details about the X-RAID system are currently unavailable due to a pending U.S. patent filing.
Since spanned volumes are AFAIK basically Windows NT's built in software RAID concentaton/JBOD I don't see any reason to have a dedicated article anymore then we don't have a dedicated article for striped volumes and mirrored volumes. Of course JBOD/concentation is not RAID but it's discussed here as it probably should be because it's the most suitable article. Having said that, we probably should add a bit more about Windows NT's built in software RAID/dynamic disks since it's not really discussed here... Nil Einne 20:16, 29 March 2006 (UTC)
I don't think it should be merged. This article is already pretty big. Definitely make it a prominent link, (or a section, with a "main article" link, and brief descriptions here), but there is too much information in the raid levels article to jam it all in here. Kaldosh 08:39, 18 March 2007 (UTC)
This article should not be merged with spanned volume. While some forms of non fault tollerent raid might relate to spanned volume, spanned volume is not fault tollerent. Do not merge the articles.
"for example, if a 120 GB disk is striped together with a 100 GB disk, the size of the array will be 200 GB"
Should that be 220Gb? Or is there some kinda storage space loss that wasn't posted? 10% loss seems like a lot of space to lose. Ghostalker 23:37, 3 April 2006 (UTC)
It is correct that a 120GB drive and 100GB drive in RAID 0 will yield 200GB. @Avernar - I am not aware of any Linux software RAID drivers being able to use the remaining space of the larger drive in RAID 0. Please document or link to the correct product and version/implimentation. Thanks. As far as I know, Windows XP cannot use in any way the extra space on the larger drive. Freedomlinux 20:21, 25 August 2006 (UTC)
"In Raid 0 there is no fault tolerance; therefore, each disk in the system is independent and there is no increase in performance."
Excuse me ? There is no increase in performance ? And clearly this is not a typo. People editing should at least know what they're talking about, this is polution!
Also, this whole paragraph about Independent vs Inexpensive is not consistent at all. It talks about data being independent (loosely defining the meaning of the usage) and claiming RAID 0,1,2 fit the definition while 4,5 (where the author says "stripping and stripping + parity", like RAID 0 wasn't striped!) would not fit the "independence" definition.
Contrast the logic: The first part of the paragraph loosely says RAID 1 and 2 are fault tolerant, therefore called independent, and later we have, "In Raid 0 there is no fault tolerance; therefore, each disk in the system is independent".
This paragraph seems like a mess to me, I would flush it.
Sorry but WHAT THE HELL ARE YOU ON ABOUT???!
RAID arrays are entirely dependant on every disk in them whilst they are functioning - no matter what RAID level is being used. If the array was to fail, then the disks would be independant but the are certainly NOT when the array is functioning. Correct definition of the term RAID is most definately Redundant array of INEXPENSIVE disks. Period.
Can anywone find benchmarks to support the claims that RAID 0 is faster? Some authors say it's not.
Sorry, Fadookie, but I think your nice new diagrams are slightly wrong/incomplete. (note I am no expert on raid, I came here to learn about it). The raid 0 and 1 diagrams seem good.
However, the raid 3 diagram is wrong because it needs to have the 'B' blocks, like in the old text diagrams. So A10 A11 A12 become B1 B2 B3. Additionally it would be nice if the 'P' secions would somehow indicate which parity data they hold (as they do in the old text diagrams). I would also change the wording of the accompanying text to "A simultaneous request for any B block would have to wait." from what it is. (It's better to wait 'til the diagrams are there, in case they change the numbering)
The raid 4 diagrams are wrong because they do not emphasize how the parity block for the 'A' blocks is on a seperate disk from the 'A' blocks (and same for the other letters). Also, I do not know about raid, but the old text diagrams also seem to indicate that the parity A block has parity covering all three other disks. If the A blocks are meant to be continuous, it also implies that even continuous data is split up among the disks. As I say, I don't know how it works, safest is to do it just like in the original text diagrams (where A is split up).
The raid 5 and 6 diagrams again doesn't show which parity block is for which data, and does not split up A blocks (and other letters) like in the text diagrams. I would again assume the text diagrams are right, and do just like them.
I haven't really looked at the rest of your diagrams. Raid 1.5 also looks wrong, but I didn't look carefully. Raid 1+0 and 10 seem OK, but better double-check. I have no clue for the double parity one.
Although the diagrams are a little bit wrong, they do look very nice!
BlankAxolotl 00:36, 26 April 2006 (UTC)
I think the introduction paragraphs need to be trimmed down, moving the extra information to appropriate sections. The first two paragraphs alone are enough to introduce the topic, the rest would flow better in appropriate sections rather than prominently at the top. What do you think? DanDanRevolution talk 15:13, 4 May 2006 (UTC)
From the 0+1 section,
"A RAID 0+1 (also called RAID 01, though it shouldn't be confused with RAID 10)"
The likely confusion is with RAID 1, not RAID 10, surely?
While it is possible that users could mistake RAID 01 for the longhand version of RAID 1. However, it RAID 01 is also VERY easily confused with RAID 10.
Example: Assuming you have 10 hard drives RAID 01 is making 2 RAID 0 arrays, then mirroring the RAID 0 arrays with RAID 1.
You end up with 2 RAID 0 arrays, each of 5 disks, then mirror the two sets of 5 together with RAID 1 to get a RAID 01 volume
RAID 10 is making 5 RAID 1 arrays, then striping them together with RAID 0.
You end up with 5 RAID 1 arrays, each containing 2 drives. Then, the 5 RAID 1 arrays are striped with RAID 0 to yield a single RAID 10 volume with 10 disks.
I am sorry if this is not exactly that clear, but I am tired and the concept is also slightly confusing. See http://www.pcguide.com/ref/hdd/perf/raid/levels/mult.htm
The Good article nomination for RAID/Archive 2 has failed, for the following reason:
ADG links to Advanced Data Guarding which redirects to RAID. Does Wikipedia:Redirect require us to mention it at the beginning of the RAID article?
http://searchstorage.techtarget.com/sDefinition/0,,sid5_gci1027532,00.html claims that RAID 6, and Advanced Data Guarding (RAID_ADG), and diagonal-parity RAID are the same thing.
But I know that RAID 6 and diagonal-parity RAID, while very, very similar, are not exactly the same. RAID-6 calculates the Q block from the same row of blocks that it calculates the parity P block (but with a different function). Diagonal-parity calculates its 2nd parity per row using the same function (XOR) that the row-parity P block is calculated with, but using a "diagonal" set of blocks.
So ... what is Advanced Data Guarding? Is it exactly the same as RAID 6, but with a catchier name? If not, how is it different? -- User:DavidCary -- 70.189.73.224 03:14, 30 May 2006 (UTC)
-- i think it would be helpful to establish up front that some raid terminology has entered common usage in ways that may not be strictly correct and to then use this idea as a structural element throughout the rest of the article. that is, for each topic make a point of treating both the correct and pop/marketing meaning of each term. that opens up the queston of what is "correct." for starters, let me suggest "as specified in the standards documents" or as "empirically demonstrable".
an example of something "empirically demonstrable" would be the idea that not all "hardware raid" implementations are implemented in hardware to the same degree. some simple mirroring or striping controllers implement all logic in hardware, some sophisticated controllers run embedded raid software on a general purpose cpu, sometimes with a coprocessor for parity. there may not be standards defining this stuff but many raid controllers have diagnostics that will tell you what's inside so you can check this.
-- some empirical data regarding performance and reliability of various raid levels might be of interest as well. calculations are very handy things, but the proof is in the pudding.
-- my original understanding of the term JBOD was that it meant just that. Just a Bunch of Drives, working independently. no concatenation, no nuttin! at that time folks were refering to concatenations as "cats" and jbods as jbods. since then i've seen the term jbod used to refer to cats, which i consider incorrect and confusing. this another area where discussing the strict and popular usage of a term would be helpful.
-- contrary to the article and in agreement with a previous comment, AFAIK raid 0 does not provide redundancy but does provide a performance benefit (all else being equall) which is the advantage it has over a concatenation. performance and reliability considerations are sometimes independant of each other.
-- as one would expect, the article focused mostly on theory. it's impossible to explore all the implementation considerations and all the permutations in a concise article (if at all). however, i think it would be worth noting that generally implementation specifics have a lot to with actual performance and that in real life "all else" is rarely equal. (go ahead and stripe all the disks you want. put a slow interconnect between the disks and your hosts, you won't see the benefit, etc.)
-- there is enough confusion about terminology in the field that we need to be very careful about checking definitions when communicating, especially when starting work with a new team, or kicking off a new client/vendor relationship.
-- i'd like to see some attention to the trade-offs involved in selecting raid configuations and how changing hardware economics change those trade-offs over time.
for example, in some cases application requirements that might have called for raid 5 on a dedicated controller a few years ago can now can be satisfied by software raid 1 because disks are bigger and cheaper and cpu cycles are cheaper too. there are also considerations of how the app behaves. offloading raid work from the cpu(s) makes a lot sense when the cpu(s) have things they can do in the mean time. if you have a host that's dedicated to a single i/o bound application that is just going to sit and wait for disk reads to complete before getting on with it, you might as well use software raid, as the cycles it uses are effectivley free. (yes, i know, that was very broad, but i'm just trying illustrate the type of subject matter i had in mind.)
-- i'm curious about the write algorthms used in various raid 1 implementations. theoretically, raid 1 should be fast on reads (if a round-robin, or race algorithm is used) and slow on writes as writes on both disks need to complete before the transaction is complete. one can imagine optimizations to the write, but they ain't free. i wonder what's actually being used especially in controllers that provide hardware assistance. i've been asked about this a few times and don't know the answer. maybe someone reading this does?
- ef
I have places tags to merge-in the section RAID parity blocks from the article Parity bit. I think this should be included on the same page as RAID, as it pertains only to RAID, and should only be referenced from the Parity bit article for further reading. This is my username; I decided to make one The7thone1188 21:28, 3 June 2006 (UTC)
OK then; It's a week later, and I have just, moved the section, removed the banners, and removed all the old links to the parity bit page. I put it at the beginning of the RAID Levels section, because that seemed logical. I've done my part, so I will unwatch the page. Please move the section if you think there is a better or more logical place for it. Thanks! The7thone1188 03:40, 11 June 2006 (UTC)
Conceptually, it's called Z RAID, as it's the end all, be all, of RAIDs. Ideally, Z RAID would be able to use a nearly unlimited number of drives of varying manufacturers, speeds, and interface connections, whether locally grouped or distributed, and would include automated detection and addition to the volume, as well as automated load balancing and throughput optimization while using a triple-parity mechanism similar to the dual-parity mechanism used by RAID 6.
This section of the Talk page is intended to foster serious consideration about the principle shortcomings of nearly all current RAID designs, and stimulate industry interest and innovation in coming up with a solution that can work for all applications.
Criteria:
1. 32-bit addressing would be required to support a virtually unlimited number of drives.
2. Storage database (similar to NTFS' MAT) required to support drives being from varying manufacturers, of differing sizes, and throughput speeds and access latencies.
3. Associated software management required to work in conjunction with the HD controller to analyze size, throughput, and latencies to provide for automated load balancing and throughput optimization.
4. It would be nice if you could use any network shared resource, including excess server or workstation space on the network.
Future benefits - This approach, if perfected, could mean the end of operating systems residing on either the workstation or the server. Instead, a single, multi-user OS could reside on all the computers, with enough fault tolerance such that you could remove a third of the computers without loss of data or program/OS code - and the OS would automatically rebuild it's self-image to re-establish the requisite redundancy on the smaller footprint, prompting the administrator to "Add storage - capacity currently too small to support maximum level of parity."
Comments, anyone? Dr1819 15:02, 10 June 2006 (UTC)
This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 | Archive 3 | Archive 4 | Archive 5 |
How about a new page (with appropriate disambiguation) for memory RAID? Not much information out there on it, but it is available and fairly easy to configure on, for instance, a Dell PowerEdge:
http://support.dell.com/support/edocs/systems/pe6850/en/it/h2147c60.htm#wp1081442
(Scroll down to Memory RAID Support.)
The contingency being: is R.A.I.D. (D now standing for DIMM, just to make matters confusing) the correct acronym?
-- 64.139.53.163 19:11, 2 March 2006 (UTC)
I don't get the sentence no
[quote] "Currently, most (all?) of the other cheap RAID BIOS products only allow one disk to participate in a single array." [/quote]
Surely that should be the other way round. no? allow a disk to participate in only a single array?
If I have
A,B,C disks A,B are for data, C for parity something like RAID 4
A,B are full and so is C I add a new buffer D,E I do not wish to "resize A,B"
Can I simply not start writing to D and simply modify the parity on C to do C= parity A,B,D, E ? if parity is XOR then simply Xorin C with new data on D xor E should suffice... (you may have to maintain a pointer as to how much on C is old parity and how much is new etc as data comes on D,E)
In other words one may not need to "restripe" everything? Is this done somewhere? It would imply treating "disks added" as bunch across which there is a stripe.
-alokdube@hotpop.com
>>>>> With present CPU speeds, software RAID can be faster than hardware RAID, though at the cost of using CPU power which might be best used for other tasks
This is totally unsubstantiated. I am unaware of a hardware raid solution that doesn't operate at the maximum hardware I/O speeds. Provide a reference to substantiate this claim.
See: http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/custom-guide/s1-raid-approaches.html
"With today's fast CPUs, Software RAID performance can excel against Hardware RAID."
>>>>>
--> wouldnt matter would it? as long as one can "plug off the BOD and put it elsewhere" and not worry, whether it is software or hardware it should not matter. However in both cases "not restriping" is a benefit.
This writing is definitely NOT up to the quality required to post to the article (I am extremely tired right now, which does not help my writing ability); could someone please proofread and post to the main article (or at least provide some suggestions on reworking it when I'm more awake)? Thanks! 70.92.160.23 05:24, 24 March 2006 (UTC)
Infrant Technologies's X-RAID is a RAID method that allows for the dynamic expansion of existing disk volumes without losing any data already present on the volume. It currently is limited to a maximum of 4 drives per RAID volume, but certain OEM products utilising custom Infrant boards have room for up to 7 drives (although the X-RAID mode will still only work with a maximum of 4 drives per volume, work is being done to increase the maximum number of drives per volume). X-RAID utilises a proprietary extension to regular Linux volume management and runs using the Ext3 filesystem. This means that X-RAID volumes can be mounted by a standard Linux installation, even when connected to a non-Infrant device. When two drives are installed in an X-RAID device, the X-RAID system runs in a redundant RAID 1 mode; with three or more drives, the device runs in a mode similar to RAID 5. X-RAID allows for the automatic expansion of volumes by replacing all disks in a volume with larger-sized disks. Once all disks are replaced, the volume automatically expands to fill the newly available space. It also allows for starting with only one disk and adding disks on-the-fly without losing any of the data already existing on the volume. Technical details about the X-RAID system are currently unavailable due to a pending U.S. patent filing.
Since spanned volumes are AFAIK basically Windows NT's built in software RAID concentaton/JBOD I don't see any reason to have a dedicated article anymore then we don't have a dedicated article for striped volumes and mirrored volumes. Of course JBOD/concentation is not RAID but it's discussed here as it probably should be because it's the most suitable article. Having said that, we probably should add a bit more about Windows NT's built in software RAID/dynamic disks since it's not really discussed here... Nil Einne 20:16, 29 March 2006 (UTC)
I don't think it should be merged. This article is already pretty big. Definitely make it a prominent link, (or a section, with a "main article" link, and brief descriptions here), but there is too much information in the raid levels article to jam it all in here. Kaldosh 08:39, 18 March 2007 (UTC)
This article should not be merged with spanned volume. While some forms of non fault tollerent raid might relate to spanned volume, spanned volume is not fault tollerent. Do not merge the articles.
"for example, if a 120 GB disk is striped together with a 100 GB disk, the size of the array will be 200 GB"
Should that be 220Gb? Or is there some kinda storage space loss that wasn't posted? 10% loss seems like a lot of space to lose. Ghostalker 23:37, 3 April 2006 (UTC)
It is correct that a 120GB drive and 100GB drive in RAID 0 will yield 200GB. @Avernar - I am not aware of any Linux software RAID drivers being able to use the remaining space of the larger drive in RAID 0. Please document or link to the correct product and version/implimentation. Thanks. As far as I know, Windows XP cannot use in any way the extra space on the larger drive. Freedomlinux 20:21, 25 August 2006 (UTC)
"In Raid 0 there is no fault tolerance; therefore, each disk in the system is independent and there is no increase in performance."
Excuse me ? There is no increase in performance ? And clearly this is not a typo. People editing should at least know what they're talking about, this is polution!
Also, this whole paragraph about Independent vs Inexpensive is not consistent at all. It talks about data being independent (loosely defining the meaning of the usage) and claiming RAID 0,1,2 fit the definition while 4,5 (where the author says "stripping and stripping + parity", like RAID 0 wasn't striped!) would not fit the "independence" definition.
Contrast the logic: The first part of the paragraph loosely says RAID 1 and 2 are fault tolerant, therefore called independent, and later we have, "In Raid 0 there is no fault tolerance; therefore, each disk in the system is independent".
This paragraph seems like a mess to me, I would flush it.
Sorry but WHAT THE HELL ARE YOU ON ABOUT???!
RAID arrays are entirely dependant on every disk in them whilst they are functioning - no matter what RAID level is being used. If the array was to fail, then the disks would be independant but the are certainly NOT when the array is functioning. Correct definition of the term RAID is most definately Redundant array of INEXPENSIVE disks. Period.
Can anywone find benchmarks to support the claims that RAID 0 is faster? Some authors say it's not.
Sorry, Fadookie, but I think your nice new diagrams are slightly wrong/incomplete. (note I am no expert on raid, I came here to learn about it). The raid 0 and 1 diagrams seem good.
However, the raid 3 diagram is wrong because it needs to have the 'B' blocks, like in the old text diagrams. So A10 A11 A12 become B1 B2 B3. Additionally it would be nice if the 'P' secions would somehow indicate which parity data they hold (as they do in the old text diagrams). I would also change the wording of the accompanying text to "A simultaneous request for any B block would have to wait." from what it is. (It's better to wait 'til the diagrams are there, in case they change the numbering)
The raid 4 diagrams are wrong because they do not emphasize how the parity block for the 'A' blocks is on a seperate disk from the 'A' blocks (and same for the other letters). Also, I do not know about raid, but the old text diagrams also seem to indicate that the parity A block has parity covering all three other disks. If the A blocks are meant to be continuous, it also implies that even continuous data is split up among the disks. As I say, I don't know how it works, safest is to do it just like in the original text diagrams (where A is split up).
The raid 5 and 6 diagrams again doesn't show which parity block is for which data, and does not split up A blocks (and other letters) like in the text diagrams. I would again assume the text diagrams are right, and do just like them.
I haven't really looked at the rest of your diagrams. Raid 1.5 also looks wrong, but I didn't look carefully. Raid 1+0 and 10 seem OK, but better double-check. I have no clue for the double parity one.
Although the diagrams are a little bit wrong, they do look very nice!
BlankAxolotl 00:36, 26 April 2006 (UTC)
I think the introduction paragraphs need to be trimmed down, moving the extra information to appropriate sections. The first two paragraphs alone are enough to introduce the topic, the rest would flow better in appropriate sections rather than prominently at the top. What do you think? DanDanRevolution talk 15:13, 4 May 2006 (UTC)
From the 0+1 section,
"A RAID 0+1 (also called RAID 01, though it shouldn't be confused with RAID 10)"
The likely confusion is with RAID 1, not RAID 10, surely?
While it is possible that users could mistake RAID 01 for the longhand version of RAID 1. However, it RAID 01 is also VERY easily confused with RAID 10.
Example: Assuming you have 10 hard drives RAID 01 is making 2 RAID 0 arrays, then mirroring the RAID 0 arrays with RAID 1.
You end up with 2 RAID 0 arrays, each of 5 disks, then mirror the two sets of 5 together with RAID 1 to get a RAID 01 volume
RAID 10 is making 5 RAID 1 arrays, then striping them together with RAID 0.
You end up with 5 RAID 1 arrays, each containing 2 drives. Then, the 5 RAID 1 arrays are striped with RAID 0 to yield a single RAID 10 volume with 10 disks.
I am sorry if this is not exactly that clear, but I am tired and the concept is also slightly confusing. See http://www.pcguide.com/ref/hdd/perf/raid/levels/mult.htm
The Good article nomination for RAID/Archive 2 has failed, for the following reason:
ADG links to Advanced Data Guarding which redirects to RAID. Does Wikipedia:Redirect require us to mention it at the beginning of the RAID article?
http://searchstorage.techtarget.com/sDefinition/0,,sid5_gci1027532,00.html claims that RAID 6, and Advanced Data Guarding (RAID_ADG), and diagonal-parity RAID are the same thing.
But I know that RAID 6 and diagonal-parity RAID, while very, very similar, are not exactly the same. RAID-6 calculates the Q block from the same row of blocks that it calculates the parity P block (but with a different function). Diagonal-parity calculates its 2nd parity per row using the same function (XOR) that the row-parity P block is calculated with, but using a "diagonal" set of blocks.
So ... what is Advanced Data Guarding? Is it exactly the same as RAID 6, but with a catchier name? If not, how is it different? -- User:DavidCary -- 70.189.73.224 03:14, 30 May 2006 (UTC)
-- i think it would be helpful to establish up front that some raid terminology has entered common usage in ways that may not be strictly correct and to then use this idea as a structural element throughout the rest of the article. that is, for each topic make a point of treating both the correct and pop/marketing meaning of each term. that opens up the queston of what is "correct." for starters, let me suggest "as specified in the standards documents" or as "empirically demonstrable".
an example of something "empirically demonstrable" would be the idea that not all "hardware raid" implementations are implemented in hardware to the same degree. some simple mirroring or striping controllers implement all logic in hardware, some sophisticated controllers run embedded raid software on a general purpose cpu, sometimes with a coprocessor for parity. there may not be standards defining this stuff but many raid controllers have diagnostics that will tell you what's inside so you can check this.
-- some empirical data regarding performance and reliability of various raid levels might be of interest as well. calculations are very handy things, but the proof is in the pudding.
-- my original understanding of the term JBOD was that it meant just that. Just a Bunch of Drives, working independently. no concatenation, no nuttin! at that time folks were refering to concatenations as "cats" and jbods as jbods. since then i've seen the term jbod used to refer to cats, which i consider incorrect and confusing. this another area where discussing the strict and popular usage of a term would be helpful.
-- contrary to the article and in agreement with a previous comment, AFAIK raid 0 does not provide redundancy but does provide a performance benefit (all else being equall) which is the advantage it has over a concatenation. performance and reliability considerations are sometimes independant of each other.
-- as one would expect, the article focused mostly on theory. it's impossible to explore all the implementation considerations and all the permutations in a concise article (if at all). however, i think it would be worth noting that generally implementation specifics have a lot to with actual performance and that in real life "all else" is rarely equal. (go ahead and stripe all the disks you want. put a slow interconnect between the disks and your hosts, you won't see the benefit, etc.)
-- there is enough confusion about terminology in the field that we need to be very careful about checking definitions when communicating, especially when starting work with a new team, or kicking off a new client/vendor relationship.
-- i'd like to see some attention to the trade-offs involved in selecting raid configuations and how changing hardware economics change those trade-offs over time.
for example, in some cases application requirements that might have called for raid 5 on a dedicated controller a few years ago can now can be satisfied by software raid 1 because disks are bigger and cheaper and cpu cycles are cheaper too. there are also considerations of how the app behaves. offloading raid work from the cpu(s) makes a lot sense when the cpu(s) have things they can do in the mean time. if you have a host that's dedicated to a single i/o bound application that is just going to sit and wait for disk reads to complete before getting on with it, you might as well use software raid, as the cycles it uses are effectivley free. (yes, i know, that was very broad, but i'm just trying illustrate the type of subject matter i had in mind.)
-- i'm curious about the write algorthms used in various raid 1 implementations. theoretically, raid 1 should be fast on reads (if a round-robin, or race algorithm is used) and slow on writes as writes on both disks need to complete before the transaction is complete. one can imagine optimizations to the write, but they ain't free. i wonder what's actually being used especially in controllers that provide hardware assistance. i've been asked about this a few times and don't know the answer. maybe someone reading this does?
- ef
I have places tags to merge-in the section RAID parity blocks from the article Parity bit. I think this should be included on the same page as RAID, as it pertains only to RAID, and should only be referenced from the Parity bit article for further reading. This is my username; I decided to make one The7thone1188 21:28, 3 June 2006 (UTC)
OK then; It's a week later, and I have just, moved the section, removed the banners, and removed all the old links to the parity bit page. I put it at the beginning of the RAID Levels section, because that seemed logical. I've done my part, so I will unwatch the page. Please move the section if you think there is a better or more logical place for it. Thanks! The7thone1188 03:40, 11 June 2006 (UTC)
Conceptually, it's called Z RAID, as it's the end all, be all, of RAIDs. Ideally, Z RAID would be able to use a nearly unlimited number of drives of varying manufacturers, speeds, and interface connections, whether locally grouped or distributed, and would include automated detection and addition to the volume, as well as automated load balancing and throughput optimization while using a triple-parity mechanism similar to the dual-parity mechanism used by RAID 6.
This section of the Talk page is intended to foster serious consideration about the principle shortcomings of nearly all current RAID designs, and stimulate industry interest and innovation in coming up with a solution that can work for all applications.
Criteria:
1. 32-bit addressing would be required to support a virtually unlimited number of drives.
2. Storage database (similar to NTFS' MAT) required to support drives being from varying manufacturers, of differing sizes, and throughput speeds and access latencies.
3. Associated software management required to work in conjunction with the HD controller to analyze size, throughput, and latencies to provide for automated load balancing and throughput optimization.
4. It would be nice if you could use any network shared resource, including excess server or workstation space on the network.
Future benefits - This approach, if perfected, could mean the end of operating systems residing on either the workstation or the server. Instead, a single, multi-user OS could reside on all the computers, with enough fault tolerance such that you could remove a third of the computers without loss of data or program/OS code - and the OS would automatically rebuild it's self-image to re-establish the requisite redundancy on the smaller footprint, prompting the administrator to "Add storage - capacity currently too small to support maximum level of parity."
Comments, anyone? Dr1819 15:02, 10 June 2006 (UTC)