RE: General RAID5 question - dangers?

I believe it is just a read on the other disks, not a rewrite... Read disk 2, and disk 1 and disk 2, write disk 1 and disk 3 parity... I do not know if any vendors do anything complicated like figure out all of the bits which were changed to recalculate the parity bit instead of reading from disk 2. If that was the case, then the complexity of that operation would be the only thing I could think of which would make mirroring more reliabe than RAID 5. I could very well be missing something though. Thanks, Will >===== Original Message From "Kudzi Muchaka" <KMuchaka@HAFresno.org> ===== >ding... (sound of light bulb coming on, thanks Mr Rice)... ah huh!!!! can i then make the assumption that if data on disk 1 is updated the parity that is rewritten will just not be an update of the changed data, but an entire rewrite of data stripe from disk 1 and data stripe from disk 2 to recreate the parity? is this always the case that there is no selective parity updates but just entire parity rewrites when data on a disk is updated? > >TIA > >-kudzi >>> William Rice <ricew@operamail.com> 06/19/00 07:50AM >>> >Even though this is addressed to Art I figured I would try to answer. > >RAID 5, say you have three disks. >1. A sector goes bad on disk2 . >2. You read read data from disk 1, >3. You write data to disk 1 >4. The parity of disk 1 and disk 2 is taken to write to the parity sector on >disk 3. >5. An hour later disk 2 blows up. >6. You have no recovery. Because the read from disk 2 when it calculated > parity was invalid. It also never went through Informix to be flagged as >bad. > >Hope this helps, >Will >>===== Original Message From "Kudzi Muchaka" <KMuchaka@HAFresno.org> ===== >>Art, >> >>i'm missing something here... must be a result of the many nights out on the >town. but my question Art is this... if in Raid 10 we are relying quite a bit >on IDS detecting bad data on a drive, why are'nt we transferring the same >dependence that IDS will detect bad data onto Raid 5. Bad data is detected >when a drive is accessed... and the probability of accessing a bad drive would >be random in both cases... right? In other words detection of bad data by IDS >would be a game of luck in either case. i think i'm >>missing something. >> >>-kudzi >> >>> "Art S. Kagel" <kagel@bloomberg.net> 06/13/00 09:36AM >>> >> >> >>William Rice wrote: >>> >>> I will admit to having some fear of RAID 5 but for different reasons. I >like >>> being >>> able to lose 3 or 4 disks and still have at least a chance of not having to >>> restore my data. This is mainly because I am a lazy bum who does >>> not like the idea of doing work which I do not have to. I am interested >>> in the theory that due to the fact that parity is calculated it is more >>> susceptible >>> to error. Would you mind adding a little more meat to that argument, or >>> is it based on more complex=more problems? Or maybe he fact that it >>> reads all the other disks to get the information to change the parity so >>> there is more oppurtunity for a problem? >> >>OK, I will deal with why RAID10 (and by extention RAID1) is not as much at >>risk. Remember that the problem is not the partial media failure trashing >>the data on the one drive that is in the process of progressively failing >>over time but the problem that good data will be read from another stripe >>member (call it drive #1) for the stripe block containing damaged data on >>the failing drive (call it drive #2) and modified causing a read of the >>remaining stripe members and the calculation of new parity after which the >>modified block will be written back to drive #1 and the parity back to that >>stripe's parity drive (perhaps drive#3). Now since the data from drive #2 >>was not needed by the application (here IDS) the fact that it was damaged >>was not detected and so the new parity was calculated using garbage >>resulting in a parity that can ONLY be used accurately to recreate the >>trashed block on drive #2. Now suppose that drive #4 suffers from a >>catastrophic failure and has to be replaced. The damaged drive has >>continued to fail and now returns a different pattern of bits than was used >>to calculate the trashed parity block on drive #3. Now when the missing >>block data on the drive #4 replacement is calculated it too will become >>garbage and two disk blocks are now unusable, the damage has propagated. >>Now that dealt with what happens if the bad block was NOT read directly and >>detected by IDS. If it was IDS will mark the chunk OFFLINE and refuse to >>use it until you repair the damage. The only way you can do that is if >>you restore from backup or remove the partially damaged drive and try to >>rebuild it from the parity as if it had completely failed. HOWEVER, if all, >>or even several, of the drives in that array are from the same manufacturing >>lot or are even of similar age, there is a good chance that the previous >>problem has already trashed the parity of other blocks so that you will >>possibly be reconstructing a new drive that will have more bad data blocks >>than the one it replaces. >> >>With RAID10, each drive in each mirrored pair is written independently. If >>a block on drive #1a is trashed the data on drive #1b (its mirror) is fine. >>If the bad data is read from the drive that is failing (say 1a) the engine >>will recognize it and mark the chunk down. All you have to do is remove >>drive 1a and mark the chunk back online rebuilding the mirror online. No >>problems and less chance that there are other damaged blocks on the one >>remaining mirror than on any of the 5 or more drives in a RAID5 stripe. If >>the data is NOT read from 1a but from 1b and modified it will be rewritten >>to BOTH drives improving the chances that it will be correctly readable if >>read from the failing 1a next time just because the flux changes will have >>been renewed, if the platter is too far gone we are just back to the >>possibility that the bad block will be read and flagged by IDS later. In >>no case can the data on 2a/2b, 3a/3b, 4a/4b, etc be damaged. Yes, if we >>were talking about ANY old data file on RAID10 the damage might propagate >>but since IDS has its own methods for detecting bad data reads this >>probability is vanishingly small (the damage to the block would have to NOT >>alter the contents of the first 28 bytes or the last 4 to 1020 bytes thus >>not damaging the page header, page trailer, or the slot table to not be >>detected by IDS). >> >>> I have never been priveleged enough to witness a site using RAID 5 have >>> serious issues, and am trying to understand where mirroring would help >>> in such a situation >> >>Lucky man! I have and let me assure you it is no privilege! >> >>Art S. Kagel > >------------------------------------------------------------ >This e-mail has been sent to you courtesy of OperaMail, as a free service from >Opera Software, makers of the award-winning Web Browser, Opera. Visit us at >http://www.opera.com/ or our portal at: http://www.myopera.com/ Your free e-mail >account is waiting at: http://www.operamail.com/ >-----------------------------------------