From 6ad9bf492b60e38e4c60bcd5ce2a18e361b4e7ce Mon Sep 17 00:00:00 2001 From: Michael Tokarev Date: Sat, 27 Sep 2014 19:40:14 +0400 Subject: remove local rebuilding-raid.html and RAID5_versus_RAID10.txt docs --- debian/FAQ | 2 - debian/README.Debian | 2 - debian/changelog | 4 + debian/docs/RAID5_versus_RAID10.txt | 177 ----------- debian/docs/rebuilding-raid.html | 561 ---------------------------------- debian/mdadm.doc-base.jd-rebuild-raid | 9 - debian/mdadm.doc-base.raid5-vs-10 | 11 - 7 files changed, 4 insertions(+), 762 deletions(-) delete mode 100644 debian/docs/RAID5_versus_RAID10.txt delete mode 100644 debian/docs/rebuilding-raid.html delete mode 100644 debian/mdadm.doc-base.jd-rebuild-raid delete mode 100644 debian/mdadm.doc-base.raid5-vs-10 (limited to 'debian') diff --git a/debian/FAQ b/debian/FAQ index 6ec1c11c..2841cf6d 100644 --- a/debian/FAQ +++ b/debian/FAQ @@ -105,8 +105,6 @@ The latest version of this FAQ is available here: 4. Which RAID level should I use? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - Please read /usr/share/doc/mdadm/RAID5_versus_RAID10.txt.gz . - Many people seem to prefer RAID4/5/6 because it makes more efficient use of space. For example, if you have disks of size X, then in order to get 2X storage, you need 3 disks for RAID5, but 4 if you use RAID10 or RAID1+0 (or diff --git a/debian/README.Debian b/debian/README.Debian index d4ce6cdf..f0897ef8 100644 --- a/debian/README.Debian +++ b/debian/README.Debian @@ -30,8 +30,6 @@ To RAID5 or not to RAID5 See http://www.miracleas.com/BAARF/BAARF2.html . The package maintainer could not possibly come up with so much emotion over such a technical topic. -See also the RAID5_versus_RAID10.txt.gz document included with this package. - Further reading ~~~~~~~~~~~~~~~ The documentation for the kernel md driver is included in diff --git a/debian/changelog b/debian/changelog index c5fe263e..913f48ed 100644 --- a/debian/changelog +++ b/debian/changelog @@ -13,6 +13,10 @@ mdadm (3.3.2-1) UNRELEASED; urgency=low * remove references to very old (pre-wheeze) breaks/replaces/depends * remove support of makedev * reformat mdadm-raid initscript a bit + * remove rebuilding-raid.html (had invisible refs) and + RAID5_versus_RAID10.txt docs. Maybe it's a good idea to remove + other docs shipped with the package, since these becoming stale + and these days, better alternatives exist online -- Michael Tokarev Sat, 20 Sep 2014 08:49:59 +0400 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 - diff --git a/debian/docs/rebuilding-raid.html b/debian/docs/rebuilding-raid.html deleted file mode 100644 index 1d7b8c0d..00000000 --- a/debian/docs/rebuilding-raid.html +++ /dev/null @@ -1,561 +0,0 @@ - - - - - - JD : /linux/rebuilding-raid - - - - - - - - - - -
- - - -
- -
-
-

Sat, 12 Jul 2008

-

Rebuilding a RAID array

I recently had a failed drive in my RAID1 array. I've just installed -the replacement drive and thought I'd share the method.

Let's look at the current situation:

-root@ace:~# cat /proc/mdstat 
-Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
-md1 : active raid1 sda3[1]
-      483403776 blocks [2/1] [_U]
-      
-md0 : active raid1 sda1[1]
-      96256 blocks [2/1] [_U]
-      
-unused devices: <none>
-

So we can see we have two mirrored arrays with one drive missing in both.

Let's see that we've recognised the second drive:

-root@ace:~# dmesg | grep sd
-[   21.465395] Driver 'sd' needs updating - please use bus_type methods
-[   21.465486] sd 2:0:0:0: [sda] 976773168 512-byte hardware sectors (500108 MB)
-[   21.465496] sd 2:0:0:0: [sda] Write Protect is off
-[   21.465498] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
-[   21.465512] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
-[   21.465562] sd 2:0:0:0: [sda] 976773168 512-byte hardware sectors (500108 MB)
-[   21.465571] sd 2:0:0:0: [sda] Write Protect is off
-[   21.465573] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
-[   21.465587] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
-[   21.465590]  sda: sda1 sda2 sda3
-[   21.487248] sd 2:0:0:0: [sda] Attached SCSI disk
-[   21.487303] sd 2:0:1:0: [sdb] 976773168 512-byte hardware sectors (500108 MB)
-[   21.487314] sd 2:0:1:0: [sdb] Write Protect is off
-[   21.487317] sd 2:0:1:0: [sdb] Mode Sense: 00 3a 00 00
-[   21.487331] sd 2:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
-[   21.487371] sd 2:0:1:0: [sdb] 976773168 512-byte hardware sectors (500108 MB)
-[   21.487381] sd 2:0:1:0: [sdb] Write Protect is off
-[   21.487382] sd 2:0:1:0: [sdb] Mode Sense: 00 3a 00 00
-[   21.487403] sd 2:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
-[   21.487407]  sdb: unknown partition table
-[   21.502763] sd 2:0:1:0: [sdb] Attached SCSI disk
-[   21.506690] sd 2:0:0:0: Attached scsi generic sg0 type 0
-[   21.506711] sd 2:0:1:0: Attached scsi generic sg1 type 0
-[   21.793835] md: bind<sda1>
-[   21.858027] md: bind<sda3>
-

So, sda has three partitions, sda1, sda2 and sda3, and sdb has no partition -table. Let's give it one the same as sda. The easiest way to do this is using -sfdisk:

-root@ace:~# sfdisk -d /dev/sda | sfdisk /dev/sdb
-Checking that no-one is using this disk right now ...
-OK
-
-Disk /dev/sdb: 60801 cylinders, 255 heads, 63 sectors/track
-
-sfdisk: ERROR: sector 0 does not have an MSDOS signature
- /dev/sdb: unrecognised partition table type
-Old situation:
-No partitions found
-New situation:
-Units = sectors of 512 bytes, counting from 0
-
-   Device Boot    Start       End   #sectors  Id  System
-/dev/sdb1   *        63    192779     192717  fd  Linux RAID autodetect
-/dev/sdb2        192780   9960299    9767520  82  Linux swap / Solaris
-/dev/sdb3       9960300 976768064  966807765  fd  Linux RAID autodetect
-/dev/sdb4             0         -          0   0  Empty
-Successfully wrote the new partition table
-
-Re-reading the partition table ...
-
-If you created or changed a DOS partition, /dev/foo7, say, then use dd(1)
-to zero the first 512 bytes:  dd if=/dev/zero of=/dev/foo7 bs=512 count=1
-(See fdisk(8).)
-

If we check dmesg now to check it's worked, we'll see:

-root@ace:~# dmesg | grep sd
-...
-[  224.246102] sd 2:0:1:0: [sdb] 976773168 512-byte hardware sectors (500108 MB)
-[  224.246322] sd 2:0:1:0: [sdb] Write Protect is off
-[  224.246325] sd 2:0:1:0: [sdb] Mode Sense: 00 3a 00 00
-[  224.246547] sd 2:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
-[  224.246686]  sdb: unknown partition table
-[  227.326278] sd 2:0:1:0: [sdb] 976773168 512-byte hardware sectors (500108 MB)
-[  227.326504] sd 2:0:1:0: [sdb] Write Protect is off
-[  227.326507] sd 2:0:1:0: [sdb] Mode Sense: 00 3a 00 00
-[  227.326703] sd 2:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
-[  227.326708]  sdb: sdb1 sdb2 sdb3
-

So, now we have identical partition tables. The next thing to do is to add the new partitions to the array:

-root@ace:~# mdadm /dev/md0 --add /dev/sdb1
-mdadm: added /dev/sdb1
-root@ace:~# mdadm /dev/md1 --add /dev/sdb3
-mdadm: added /dev/sdb3
-

Everything looks good. Let's check dmesg:

-[  323.941542] md: bind<sdb1>
-[  324.038183] RAID1 conf printout:
-[  324.038189]  --- wd:1 rd:2
-[  324.038192]  disk 0, wo:1, o:1, dev:sdb1
-[  324.038195]  disk 1, wo:0, o:1, dev:sda1
-[  324.038300] md: recovery of RAID array md0
-[  324.038303] md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
-[  324.038305] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for recovery.
-[  324.038310] md: using 128k window, over a total of 96256 blocks.
-[  325.417219] md: md0: recovery done.
-[  325.453629] RAID1 conf printout:
-[  325.453632]  --- wd:2 rd:2
-[  325.453634]  disk 0, wo:0, o:1, dev:sdb1
-[  325.453636]  disk 1, wo:0, o:1, dev:sda1
-[  347.970105] md: bind<sdb3>
-[  348.004566] RAID1 conf printout:
-[  348.004571]  --- wd:1 rd:2
-[  348.004573]  disk 0, wo:1, o:1, dev:sdb3
-[  348.004574]  disk 1, wo:0, o:1, dev:sda3
-[  348.004657] md: recovery of RAID array md1
-[  348.004659] md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
-[  348.004660] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for recovery.
-[  348.004664] md: using 128k window, over a total of 483403776 blocks.
-

Everything still looks good. Let's sit back and watch it rebuild using the wonderfully useful watch command:

-root@ace:~# watch -n 1 cat /proc/mdstat
-Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
-md1 : active raid1 sdb3[2] sda3[1]
-      483403776 blocks [2/1] [_U]
-      [=====>...............]  recovery = 26.0% (126080960/483403776) finish=96.2min speed=61846K/sec
-      
-md0 : active raid1 sdb1[0] sda1[1]
-      96256 blocks [2/2] [UU]
-      
-unused devices: <none>
-

The Ubuntu and Debian installers will allow you create RAID1 arrays -with less drives than you actually have, so you can use this technique -if you plan to add an additional drive after you've installed the -system. Just tell it the eventual number of drives, but only select the -available partitions during RAID setup. I used this method when a new machine recent -didn't have enough SATA power cables and had to wait for an adaptor to -be delivered.

(Why did no one tell me about watch until recently. I wonder -how many more incredibly useful programs I've not discovered even after 10 -years of using Linux)

- [, , ] | # Read Comments (3) | -
-
- -
- -
-

Comments

-
-
- One extra step that I do is install an MBR on the new disk, to make it bootable:
-
-install-mbr /dev/sdb
- Posted by Marius Gedminas at Sun Jul 13 07:51:06 2008 -
-
- Great article!
-Maybe it would be even more useful if merged here:
-http://linux-raid.osdl.org/index.php/Reconstruction
- Posted by Eduardo Pérez Ureta at Sun Jul 13 18:54:07 2008 -
-
- Semi-Tangential note about performance:  On my home (== partly "play") machine, I made the experience that "mdadm --manage .. --fail"-ing the root partition before doing lots of package upgrades (installing KDE 4/experimental and lots of other updates in my case, on a mostly etch system.  Dual screen support sucks if the screens don't have the same size, btw!) speeds up apt considerably, while the subsequent reconstruct step (--remove and then --add the partition) doesn't slow down the system much during light desktop workload.
-
-My system is a few years old (no SATA, probably not too much cache on the disks, too) and has only 512M RAM, so maybe a better equipped system would make this less noticeable.
-
-(... and no, I probably wouldn't force-fail part of my /home partition for any length of time :-)
- Posted by cmot at Mon Jul 14 12:30:50 2008 -
-
-
-
-

- Name:
-
-
- E-mail:
-
-
- URL:
- -
-
- Comment:
-
-
- Please enter "fudge" to prove you are a human - -
- - -

-
-
-
-
-
- -
-
- - diff --git a/debian/mdadm.doc-base.jd-rebuild-raid b/debian/mdadm.doc-base.jd-rebuild-raid deleted file mode 100644 index b1cb73cb..00000000 --- a/debian/mdadm.doc-base.jd-rebuild-raid +++ /dev/null @@ -1,9 +0,0 @@ -Document: mdadm-jd-rebuild-raid -Title: Rebuilding a RAID array -Author: David Pashley -Abstract: The document describes how to replace a failed component in a RAID(1) array -Section: System/Administration - -Format: HTML -Index: /usr/share/doc/mdadm/rebuilding-raid.html -Files: /usr/share/doc/mdadm/rebuilding-raid.html diff --git a/debian/mdadm.doc-base.raid5-vs-10 b/debian/mdadm.doc-base.raid5-vs-10 deleted file mode 100644 index 47416e53..00000000 --- a/debian/mdadm.doc-base.raid5-vs-10 +++ /dev/null @@ -1,11 +0,0 @@ -Document: mdadm-raid5-vs-10 -Title: Comparison of RAID5 and RAID10 -Author: Art S. Kagel -Abstract: This document compares RAID5 and RAID10 and strongly argues against - RAID5. The Debian package maintainer does not agree in full but includes the - document to allow people to make up their own mind. -Section: System/Administration - -Format: text -Index: /usr/share/doc/mdadm/RAID5_versus_RAID10.txt.gz -Files: /usr/share/doc/mdadm/RAID5_versus_RAID10.txt.gz -- cgit v1.2.3