Re: I LOVE RAID 5!!!!!!!!!!!!!!!!!!!!!

From: malc_p@my-deja.com > >ALL RIGHT. Now I've got your attention, please ignore the subject line. >What I need to know (in order to overrule an IT manager who is >determined to install a RAID setup and won't listen to any arguments >against) is exactly WHAT the disadvantages / advantages are between >using RAID and JBOD. I tried earlier but the only reply I got was from >one Mr. O. Clown (thanx, btw). >I think I need to push JBOD but there's a huge difference between gut >feeling and reasoned debate. >Exactly why does Art hate RAID 5 so much? He keeps saying NO RAID 5! NO >RAID 5! etc. ad nauseam but WHY? I keep this handy, it seems to be my most regular (useful) contribution :) From Art Kagel: >Most of those disparaging postings are from me. There are two problems >with RAID5. The first is performance which is the one most people notice >and if you can live with write throughput which is 50% of the equivalent >RAID0 stripe set then that is fine. The performance hit is caused because >RAID5 ONLY reads the one drive containing the requested sector leaving the >other drives free to return other sectors from different stripe blocks. >This is the reason that RAID5 is preferred to RAID3 or RAID4 for >filesystems, this feature improved small random read performance. However, >since the parity and the balance of the stripe block were not read, if you >rewrite the block (which databases do far more frequently than filesytems) >the other drives must all be read and a new parity calculated and then >both the modified block and the parity block must be written back to disk. >This READ-WRITE-READ-WRITE for each modified block is the reason RAID5 is >so poor in terms of write throughput. Large RAID controller caches and >on controller firmware level RAID implementations alleviate the problem >somewhat but not completely and write performance still hovers at around >half what a pure stripe (RADI0) would get. > >The second problem, despite what others have said IS a FUNDAMENTAL problem >with the design of RAID5 which various implementors have tried to correct >with varying levels of success. The problem is that if a drive fails >slowly over time, known as partial media failure, where periodically a >sector or two goes bad, this is NOT detected by RAID5's parity and so >is propagated to the parity when that sector is rewritten which means that >if another drive fails catastrophically its data will be rebuilt utilizing >damaged parity resulting in two sectors with garbage. Now this may not >even be noticed for a long time as modern SCSI drives automatically remap >bad sectors to a set of sectors set asside for the purpose but the >corrected error is NOT reported to the OS or the administrators. Over >time if the drive is going it will run out of remap sectors and will have >to begin returning data reconstructed from the drive's own ECC codes. >Eventually the damage will exceed the ECC's ability to rebuild a single >bit error per byte and will return garbage. > >RAID3 and RAID4 are superior in both areas. In both all drives are read >for any block which improves sequential read performance (Informix Read >Ahead depends on sequential read performance) over RAID5 and parity can >be (and in most implementations IS) checked at read time so that partial >media failure problems can be detected. Write performance is >approximately the same as RAID0 for large writes or smaller stripe block >sizes. One problem with early implementations of RAID3/4 was slow parity >checking since it has to be calculated for every read and every write. >Modern controller based RAID systems use the on-board processor on the >SCSI controller to perform the parity checks without impacting system >performance by tying up the a system CPU to check and produce parity. >These RAID levels require the exact same number of drives as RAID5. > >RAID10 provides the best protection and performance with read performance >exceeding any other RAID level (since both drives of a mirrored pair can >be reading different sectors on parallel) and write performance is closest >to pure striping. Indeed in a hardware/firmware implemented RAID10 array >with on-board cache apparent write throughput can exceed RAID0 for brief >periods due to the two drives of each pair being written to independently >though the gain is not sustainable over time. > >A third problem with ALL RAID3/4/5 from which RAID10 does not suffer is >multiple drive failure. (Ever get a batch or 200 bad drives? We have!) >If one drive in a RAID3/4/5 array fails catastrophically you are at risk >for complete data loss if ANY of the remaining 4 (or more) drives should >fail before the original failed drive can be replaced and rebuilt. With >RAID10, since it is made up as a stripe set of N mirrored pairs, when a >drive fails you are only at risk for complete data loss if that one drives >particular mirror partner should fail. Make each mirrored pair from >drives selected from different manufacturer's lots and the probability of >this happening become vanishingly small. > >Fourth problem. During drive rebuild RAID3/4/5 (and RAID01 mirrored >stripe sets) performance of the array during the rebuild can degrade by >as much as 80%! Some RAID systems let you tune the relative priority of >rebuild versus production to reduce the performance hit to as low as about >40% degradation but this will increase the recovery time increasing the >number of production requests that are degraded and increasing the risk >of the previous problem with a second drive failure. RAID10, since only >one drive is involved in mirror recovery, the array's performance (for a >4 drive array) is degraded only a maximum of 80% for reads and writes >against the failed pair and only slightly (due to controller traffic) for >accesses to the other drives, on average, since the one pair comprises >only 20% of accesses, performance is affected no more than 16% during >recovery and the risk of catastrophic data loss is reduced. > >Well this concludes my quarterly RAID5 rant for anyone who has had trouble >finding my earlier ones. > >Art S. Kagel All I can add is that I've seen a RAID 5 go without any warning, and it was ugly. Also, I reckon Art has more disk under his domain than anyone I know of, and the fact that he switched from RAID5 to RAID10 to get some sleep in spite of the extra costs is a pretty convincing argument. :-) _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com.

WARNING!!!!!!!!!!!!!!!!!!!!!! SHAMELESS PLUG FOLLOWS!!!!!!!! I have no financial interest in SEEK Systems, but I am a very happy customer. They provide a nifty way of letting your hardware decide about what RAID level might work best. We use their Adaptive RAID system. IT monitors how your RAID system is being used, and then configures itself on the fly over time to provide the best RAID performance. We currently use Informix 7.3.x on AIX 4.3.x. Our OLTP setup is small compared to most of you write about: 19 Gig with about 200 concurrent users. Our RS6000 box has 2 Gig RAM with 1.5 Gig devoted to Informix. Our Adaptive RAID system has 9 drives at 10Gig each. It started out configured as a RAID5 system. After about 3 months it slowly shifted itself to RAID-something-else; and system throughput has increased. We did get a reasonably large cache with the controller (256Meg), and there are parameters one can monitor and tweak if need be. The system seems to address Art's concerns in large measure. Indeed, it was our reading of Art's comments that started our search for a reasonably priced solution for our company. Again, we have no financial interest, but we are happy. Obnoxio The Clown <obnoxio@hotmail.com> wrote in article <8tp38h$cot$1@news.xmission.com>... > > All I can add is that I've seen a RAID 5 go without any warning, and it was > ugly. Also, I reckon Art has more disk under his domain than anyone I know > of, and the fact that he switched from RAID5 to RAID10 to get some sleep in > spite of the extra costs is a pretty convincing argument. :-) > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > Share information about yourself, create your own public profile at > http://profiles.msn.com. > >