diff options
Diffstat (limited to 'debian/patches')
-rwxr-xr-x | debian/patches/99-raid5-vs-raid10-doc.dpatch | 182 |
1 files changed, 182 insertions, 0 deletions
diff --git a/debian/patches/99-raid5-vs-raid10-doc.dpatch b/debian/patches/99-raid5-vs-raid10-doc.dpatch new file mode 100755 index 00000000..8ce253de --- /dev/null +++ b/debian/patches/99-raid5-vs-raid10-doc.dpatch @@ -0,0 +1,182 @@ +#! /bin/sh /usr/share/dpatch/dpatch-run +## 99-raid5-vs-raid10-doc.dpatch by martin f. krafft <madduck@debian.org> +## +## All lines beginning with `## DP:' are a description of the patch. +## DP: No description. + +@DPATCH@ +diff -urNad trunk~/RAID5_versus_RAID10.txt trunk/RAID5_versus_RAID10.txt +--- trunk~/RAID5_versus_RAID10.txt 1970-01-01 01:00:00.000000000 +0100 ++++ trunk/RAID5_versus_RAID10.txt 2006-07-24 23:06:52.373326792 +0100 +@@ -0,0 +1,171 @@ ++# from http://www.miracleas.com/BAARF/RAID5_versus_RAID10.txt ++# ++# note: I, the Debian maintainer, do not agree with much of what's written ++# here, but it's a good argument the author is putting forth. In the end, the ++# RAID level you choose depends on your needs only. ++# ++ ++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 RAID01 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 ++ |