diff options
Diffstat (limited to 'debian/docs/RAID5_versus_RAID10.txt')
| -rw-r--r-- | debian/docs/RAID5_versus_RAID10.txt | 177 |
1 files changed, 0 insertions, 177 deletions
diff --git a/debian/docs/RAID5_versus_RAID10.txt b/debian/docs/RAID5_versus_RAID10.txt deleted file mode 100644 index 8278ab26..00000000 --- a/debian/docs/RAID5_versus_RAID10.txt +++ /dev/null @@ -1,177 +0,0 @@ -# from http://www.miracleas.com/BAARF/RAID5_versus_RAID10.txt -# also see http://www.miracleas.com/BAARF/BAARF2.html -# -# Note: I, the Debian maintainer, do not agree with some of the arguments, -# especially not with the total condemning of RAID5. Anyone who talks about -# data loss and blames the RAID system should spend time reading up on Backups -# instead of trying to evangelise, but that's only my opinion. RAID5 has its -# merits and its shortcomings, just like any other method. However, the author -# of this argument puts forth a good case and thus I am including the -# document. Remember that you're the only one that can decide which RAID level -# to use. -# - -RAID5 versus RAID10 (or even RAID3 or RAID4) - -First let's get on the same page so we're all talking about apples. - -What is RAID5? - -OK here is the deal, RAID5 uses ONLY ONE parity drive per stripe and many -RAID5 arrays are 5 (if your counts are different adjust the calculations -appropriately) drives (4 data and 1 parity though it is not a single drive -that is holding all of the parity as in RAID 3 & 4 but read on). If you -have 10 drives or say 20GB each for 200GB RAID5 will use 20% for parity -(assuming you set it up as two 5 drive arrays) so you will have 160GB of -storage. Now since RAID10, like mirroring (RAID1), uses 1 (or more) mirror -drive for each primary drive you are using 50% for redundancy so to get the -same 160GB of storage you will need 8 pairs or 16 - 20GB drives, which is -why RAID5 is so popular. This intro is just to put things into -perspective. - -RAID5 is physically a stripe set like RAID0 but with data recovery -included. RAID5 reserves one disk block out of each stripe block for -parity data. The parity block contains an error correction code which can -correct any error in the RAID5 block, in effect it is used in combination -with the remaining data blocks to recreate any single missing block, gone -missing because a drive has failed. The innovation of RAID5 over RAID3 & -RAID4 is that the parity is distributed on a round robin basis so that -there can be independent reading of different blocks from the several -drives. This is why RAID5 became more popular than RAID3 & RAID4 which -must sychronously read the same block from all drives together. So, if -Drive2 fails blocks 1,2,4,5,6 & 7 are data blocks on this drive and blocks -3 and 8 are parity blocks on this drive. So that means that the parity on -Drive5 will be used to recreate the data block from Disk2 if block 1 is -requested before a new drive replaces Drive2 or during the rebuilding of -the new Drive2 replacement. Likewise the parity on Drive1 will be used to -repair block 2 and the parity on Drive3 will repair block4, etc. For block -2 all the data is safely on the remaining drives but during the rebuilding -of Drive2's replacement a new parity block will be calculated from the -block 2 data and will be written to Drive 2. - -Now when a disk block is read from the array the RAID software/firmware -calculates which RAID block contains the disk block, which drive the disk -block is on and which drive contains the parity block for that RAID block -and reads ONLY the one data drive. It returns the data block. If you -later modify the data block it recalculates the parity by subtracting the -old block and adding in the new version then in two separate operations it -writes the data block followed by the new parity block. To do this it must -first read the parity block from whichever drive contains the parity for -that stripe block and reread the unmodified data for the updated block from -the original drive. This read-read-write-write is known as the RAID5 write -penalty since these two writes are sequential and synchronous the write -system call cannot return until the reread and both writes complete, for -safety, so writing to RAID5 is up to 50% slower than RAID0 for an array of -the same capacity. (Some software RAID5's avoid the re-read by keeping an -unmodified copy of the orginal block in memory.) - -Now what is RAID10: - -RAID10 is one of the combinations of RAID1 (mirroring) and RAID0 -(striping) which are possible. There used to be confusion about what -RAID01 or RAID10 meant and different RAID vendors defined them -differently. About five years or so ago I proposed the following standard -language which seems to have taken hold. When N mirrored pairs are -striped together this is called RAID10 because the mirroring (RAID1) is -applied before striping (RAID0). The other option is to create two stripe -sets and mirror them one to the other, this is known as RAID01 (because -the RAID0 is applied first). In either a RAID01 or RAID10 system each and -every disk block is completely duplicated on its drive's mirror. -Performance-wise both RAID01 and RAID10 are functionally equivalent. The -difference comes in during recovery where RAID01 suffers from some of the -same problems I will describe affecting RAID5 while RAID10 does not. - -Now if a drive in the RAID5 array dies, is removed, or is shut off data is -returned by reading the blocks from the remaining drives and calculating -the missing data using the parity, assuming the defunct drive is not the -parity block drive for that RAID block. Note that it takes 4 physical -reads to replace the missing disk block (for a 5 drive array) for four out -of every five disk blocks leading to a 64% performance degradation until -the problem is discovered and a new drive can be mapped in to begin -recovery. Performance is degraded further during recovery because all -drives are being actively accessed in order to rebuild the replacement -drive (see below). - -If a drive in the RAID10 array dies data is returned from its mirror drive -in a single read with only minor (6.25% on average for a 4 pair array as a -whole) performance reduction when two non-contiguous blocks are needed from -the damaged pair (since the two blocks cannot be read in parallel from both -drives) and none otherwise. - -One begins to get an inkling of what is going on and why I dislike RAID5, -but, as they say on late night info-mercials, there's more. - -What's wrong besides a bit of performance I don't know I'm missing? - -OK, so that brings us to the final question of the day which is: What is -the problem with RAID5? It does recover a failed drive right? So writes -are slower, I don't do enough writing to worry about it and the cache -helps a lot also, I've got LOTS of cache! The problem is that despite the -improved reliability of modern drives and the improved error correction -codes on most drives, and even despite the additional 8 bytes of error -correction that EMC puts on every Clariion drive disk block (if you are -lucky enough to use EMC systems), it is more than a little possible that a -drive will become flaky and begin to return garbage. This is known as -partial media failure. Now SCSI controllers reserve several hundred disk -blocks to be remapped to replace fading sectors with unused ones, but if -the drive is going these will not last very long and will run out and SCSI -does NOT report correctable errors back to the OS! Therefore you will not -know the drive is becoming unstable until it is too late and there are no -more replacement sectors and the drive begins to return garbage. [Note -that the recently popular IDE/ATA drives do not (TMK) include bad sector -remapping in their hardware so garbage is returned that much sooner.] -When a drive returns garbage, since RAID5 does not EVER check parity on -read (RAID3 & RAID4 do BTW and both perform better for databases than -RAID5 to boot) when you write the garbage sector back garbage parity will -be calculated and your RAID5 integrity is lost! Similarly if a drive -fails and one of the remaining drives is flaky the replacement will be -rebuilt with garbage also propagating the problem to two blocks instead of -just one. - -Need more? During recovery, read performance for a RAID5 array is -degraded by as much as 80%. Some advanced arrays let you configure the -preference more toward recovery or toward performance. However, doing so -will increase recovery time and increase the likelihood of losing a second -drive in the array before recovery completes resulting in catastrophic -data loss. RAID10 on the other hand will only be recovering one drive out -of 4 or more pairs with performance ONLY of reads from the recovering pair -degraded making the performance hit to the array overall only about 20%! -Plus there is no parity calculation time used during recovery - it's a -straight data copy. - -What about that thing about losing a second drive? Well with RAID10 there -is no danger unless the one mirror that is recovering also fails and -that's 80% or more less likely than that any other drive in a RAID5 array -will fail! And since most multiple drive failures are caused by -undetected manufacturing defects you can make even this possibility -vanishingly small by making sure to mirror every drive with one from a -different manufacturer's lot number. ("Oh", you say, "this schenario does -not seem likely!" Pooh, we lost 50 drives over two weeks when a batch of -200 IBM drives began to fail. IBM discovered that the single lot of -drives would have their spindle bearings freeze after so many hours of -operation. Fortunately due in part to RAID10 and in part to a herculean -effort by DG techs and our own people over 2 weeks no data was lost. -HOWEVER, one RAID5 filesystem was a total loss after a second drive failed -during recover. Fortunately everything was on tape. - -Conclusion? For safety and performance favor RAID10 first, RAID3 second, -RAID4 third, and RAID5 last! The original reason for the RAID2-5 specs -was that the high cost of disks was making RAID1, mirroring, impractical. -That is no longer the case! Drives are commodity priced, even the biggest -fastest drives are cheaper in absolute dollars than drives were then and -cost per MB is a tiny fraction of what it was. Does RAID5 make ANY sense -anymore? Obviously I think not. - -To put things into perspective: If a drive costs $1000US (and most are far -less expensive than that) then switching from a 4 pair RAID10 array to a 5 -drive RAID5 array will save 3 drives or $3000US. What is the cost of -overtime, wear and tear on the technicians, DBAs, managers, and customers -of even a recovery scare? What is the cost of reduced performance and -possibly reduced customer satisfaction? Finally what is the cost of lost -business if data is unrecoverable? I maintain that the drives are FAR -cheaper! Hence my mantra: - -NO RAID5! NO RAID5! NO RAID5! NO RAID5! NO RAID5! NO RAID5! NO RAID5! - -Art S. Kagel - |