This is all for RAID1. And it's written in December 2010 with reference to mdadm 2.6.7.2 running on Debian 5 (Lenny), or any other Linux system with a 2.6.26-ish kernel.<\/p>\n
First, set up some partitions — normally in equal-sized pairs on different disks. Let's assume the pair is \/dev\/sda1 and \/dev\/sdb1, to be combined as \/dev\/md0 (yes, I know — normal partitions are numbered from , RAID ones from 0. Trying to line up \/dev\/sd?1 with \/dev\/md1 seems to cause problems when automatic numbering kicks in, so live with it.)<\/p>\n
Create the RAID partition:<\/p>\n
or, if only one partition is available, that can be<\/p>\n That will start the process of syncing the two partitions, which can take a long time if they're big, even if they were initially empty.<\/p>\n What happens if both contained data? If either contain partitions or filing systems, mdadm will prompt for continuation. The data (i.e. everything, including the partition table) contained in the first-named partition will overwrite the second partition when the array syncs. Syncing only happens when the array is mounted — until then it is marked as 'pending'.<\/p>\n Before I go on, I'll look for some existing information. Here's some: http:\/\/www.ducea.com\/2009\/03\/08\/mdadm-cheat-sheet\/<\/p>\n So I'll copy and paste a big chunk of that, and annotate it to my taste.<\/p>\n Create ( \/etc\/mdadm.conf or \/etc\/mdadm\/mdadm.conf (on debian) is the main configuration file for mdadm. After we create our RAID arrays we add them to this file using: We can’t remove a disk directly from the array, unless it is marked as 'failed', so we first have to fail it. (If the drive has really failed, the mdadm should have detected this and so this step will not be needed): This can be done in a single step using: These commands are what mdadm calls 'management' mode, as opposed to the 'create', 'assemble' etc., modes.<\/p>\n We can add a new disk to an array (replacing a failed one probably): This will only work if \/dev\/sdb1 does not already have a superblock, i.e. it has not already been made part of an array.<\/p>\n If it has a superblock, that can be removed with: See http:\/\/en.wikipedia.org\/wiki\/Mdadm#Known_problems<\/span><\/p>\n We can check the status of the arrays on the system with: The output of this command will look like:<\/p>\n Here we can see both drives are used and working fine – U<\/strong>. A failed drive will show as F<\/strong>, while a degraded array will having missing partitions marked with –<\/strong>.<\/p>\n Note: while monitoring the status of a RAID rebuild operation using watch can be useful: If we want to completely remove a raid array we have to stop if first and then remove it: That presumably leaves two normal partitions, which will have identical contents if syncing was up-to-date. They could then be recreated into an array with –create (but that would keep the contents of the first-named).<\/p>\n If the system is set up correctly (whatever that means), RAID arrays will be assembled when the machine is booted.<\/p>\n If not, partitions that have previously belonged to an array can be linked together: For more convenience, mdadm will scan partitions for matching superblocks and start the arrays automatically: (when I was sorting out RAID on an HP Proliant server)<\/p>\n Because of dmraid. If the BIOS has been used to create a fake-raid array in the past, even if you've now chosen not to use it, dmraid will notice the signature on the drives and will take them over, getting in the way of mdadm. See http:\/\/en.wikipedia.org\/wiki\/Mdadm#Known_problems.<\/p>\n Normally, Knoppix sorts out RAID well. It doesn't seem to create arrays automatically, but a simple Will only daemonize and monitor things if there's an email address or program name in \/etc\/mdadm\/mdadm.conf.<\/p>\n So, for information about other events, we need the specified 'program' to be a script that sends a suitable email. Easy, but not particularly useful. Looking at \/etc\/init.d (on Debian Lenny), there are two processes that get run automatically:<\/p>\n There's some configuration in \/etc\/default\/mdadm, as set up when the mdadm package is configured.<\/p>\n Monitoring also happens as controlled by \/etc\/cron.d\/mdadm, which runs \/usr\/share\/mdadm\/checkarray once a month.<\/p>\n <\/p>\n Finally in using RAID1 arrays, where we create identical partitions<\/strong> on both drives this can be useful to copy the partitions from sda to sdb: (this will dump the partition table of sda, removing completely the existing partitions on sdb, so be sure you want this before running this command, as it will not warn you at all).<\/p>\n Boot partition: should grub be on \/dev\/sda1 and \/dev\/sda2, or on \/dev\/md0? The latter I think, now that Grub is capable of such things. <\/p>\n Aha! That's all very well, but where does the BIOS find grub? Some BIOSes will just boot from 'a hard drive', others from a specific hard drive. For example, a HP Proliant I've been working on mentions specific drives. It was willing to boot from a fake-raid array (using nVidia MediaShield), but I opted for mdadm software RAID instead. Leaving the BIOS point to one of the drives: if it fails, a BIOS tweak will presumably be required. It didn't have an option for 'try this hard drive, and then try the other one.<\/p>\n Likewise swap: it won't be any slower on RAID1, and we won't have to tweak things<\/p>\n","protected":false},"excerpt":{"rendered":" This is all for RAID1. And it's written in December 2010 with reference to mdadm 2.6.7.2 running on Debian 5 (Lenny), or any other Linux system with a 2.6.26-ish kernel. First, set up some partitions — normally in equal-sized pairs on different disks. Let's assume the pair is \/dev\/sda1 and \/dev\/sdb1, to be combined as […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[7,29,35],"tags":[],"_links":{"self":[{"href":"https:\/\/wp.fbcs.co.uk\/wp-json\/wp\/v2\/posts\/76"}],"collection":[{"href":"https:\/\/wp.fbcs.co.uk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/wp.fbcs.co.uk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/wp.fbcs.co.uk\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/wp.fbcs.co.uk\/wp-json\/wp\/v2\/comments?post=76"}],"version-history":[{"count":0,"href":"https:\/\/wp.fbcs.co.uk\/wp-json\/wp\/v2\/posts\/76\/revisions"}],"wp:attachment":[{"href":"https:\/\/wp.fbcs.co.uk\/wp-json\/wp\/v2\/media?parent=76"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/wp.fbcs.co.uk\/wp-json\/wp\/v2\/categories?post=76"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/wp.fbcs.co.uk\/wp-json\/wp\/v2\/tags?post=76"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}mdadm --create -n 2 --level 1 \/dev\/md0 \/dev\/sda1 \/dev\/sdb1<\/code><\/p>\nmdadm --create -n 2 --level 1 \/dev\/md0 \/dev\/sda1 missing<\/code><\/p>\n1. Create a new RAID array<\/h3>\n
mdadm --create<\/code>) is used to create a new array:
\n\tmdadm --create --verbose \/dev\/md0 --level=1 \/dev\/sda1 \/dev\/sdb2<\/code>
\n\tor using the compact notation:
\n\tmdadm -Cv \/dev\/md0 -l1 -n2 \/dev\/sd[ab]1<\/code><\/p>\n2. \/etc\/mdadm.conf<\/h3>\n
\n\tmdadm --detail --scan >> \/etc\/mdadm.conf<\/code>
\n\tor on debian
\n\tmdadm --detail --scan >> \/etc\/mdadm\/mdadm.conf<\/code><\/p>\n3. Remove a disk from an array<\/h3>\n
\n\tmdadm --fail \/dev\/md0 \/dev\/sda1<\/code>
\n\tand now we can remove it:
\n\tmdadm --remove \/dev\/md0 \/dev\/sda1<\/code><\/p>\n
\n\tmdadm \/dev\/md0 --fail \/dev\/sda1 --remove \/dev\/sda1<\/code><\/p>\n4. Add a disk to an existing array<\/h3>\n
\n\tmdadm --add \/dev\/md0 \/dev\/sdb1<\/code><\/p>\n
\n\tmdadm --zero \/dev\/sdb1<\/code>
\n\tThis will potentially lose data since the 'array' is considered to contain the up-to-date data, and the newly added partition will be overwritten.<\/p>\n5. Verifying the status of the RAID array<\/h3>\n
\n\tcat \/proc\/mdstat<\/code>
\n\tor
\n\tmdadm --detail \/dev\/md0<\/code><\/p>\n# cat \/proc\/mdstat\nPersonalities : [raid1]\nmd0 : active raid1 sdb1[1] sda1[0]\n104320 blocks [2\/2] [UU]\n\nmd1 : active raid1 sdb3[1] sda3[0]\n19542976 blocks [2\/2] [UU]\n\nmd2 : active raid1 sdb4[1] sda4[0]\n223504192 blocks [2\/2] [UU]<\/code><\/pre>\n
\n\twatch cat \/proc\/mdstat<\/code><\/p>\n6. Stop and delete a RAID array<\/h3>\n
\n\tmdadm --stop \/dev\/md0
\n\tmdadm --remove \/dev\/md0<\/code>
\n\tand finally we can even delete the superblock from the individual partitions:
\n\tmdadm --zero-superblock \/dev\/sd[ab]1
\n\t<\/code><\/p>\n7. Assembling<\/h3>\n
\n\tmdadm --assemble \/dev\/md0 \/dev\/sd[ab]1<\/code><\/p>\n
\n\tmdadm --assemble --scan<\/code>
\n\twhich is presumably what happens at boot time.<\/p>\n7a. Knoppix — why did that not work?<\/h3>\n
\n\tmdadm --assemble --scan<\/code>
\n\twill start any arrays that it finds.<\/p>\n8. Monitoring<\/h3>\n
Only Fail, FailSpare, DegradedArray, SparesMissing and TestMessage cause Email to be sent. All events cause the program to be run. The program is run with two or three arguments: the event name, the array device and possibly a second device.<\/q><\/p>\n
\n\t<\/code><\/p>\n\n
Other things to do<\/h3>\n
\n\tsfdisk -d \/dev\/sda | sfdisk \/dev\/sdb<\/code><\/p>\nThings to sort out:<\/h3>\n