If you have inherited a system that already uses software RAID, you need to decide whether you’re going to continue maintaining that array or retire it and migrate the data to a new array (hardware or software). The rest of this chapter focuses on con-structing new software arrays. If you plan to keep maintaining an array that already exists, read Chapters 4 and 7.
If you want to scrap an existing RAID, this section offers some advice that will help you dismantle the array. It’s vital to keep in mind that reconfiguring an array or reus-ing its member disks in new arrays means that existreus-ing data will be lost. So it’s very important to back up any data before proceeding.
In certain cases, it’s possible to remove a member disk without losing data on an array. For example, removing an unused spare disk from a RAID-1 or RAID-5 will not cause data loss, although it might reduce fault tolerance.
If you plan to scrap all your existing arrays and use hardware RAID, skip straight to Chapter 5; the preparatory steps in this section do not apply to that situation.
Finally, if you are experimenting with various RAID levels and plan to reuse parti-tions that you have already included in another array, you might need to take some additional steps before building the new array. Remember that reusing these parti-tions means that the data on them will be destroyed, along with your array. Further-more, you will not be able create a new array using partitions that are members of an array that is already running. So to reuse disks, you’ll first have to stop any active arrays of which they are members.
Stopping an array
The raidstop command can be used to deactivate a running array created or started using raidtools:
# raidstop /dev/md0
Here’s how to stop an array using mdadm:
# mdadm -S /dev/md0
If an array contains a mounted filesystem, both raidstop and mdadm will return an error. Filesystems should be unmounted using the umount command before they are stopped.
Once an array is stopped, its resources (member disks and md device special files) can be reclaimed and used in new arrays. If you attempt to use a member disk that is already part of a running array, mkraid and mdadm will generate errors on the com-mand line, warning that the device is already part of an array. The md driver will also generate errors using syslog. Likewise, if you attempt to create an array using a device special file that is already in use, mkraid and mdadm will generate device busy errors, and the md driver will record them using syslog.
Reusing member disks
Some of the techniques used in this section can result in data loss or corruption if they are used improperly, or even if you make a simple typo at the command line. Please be extremely cautious when attempt-ing them.
Whenever you attempt to create new array using mdadm or mkraid, you will be warned about using member disks that already have a RAID superblock on them, even if they’re not part of an array that’s currently in use. So if you have a dormant disk in your system and it used to be part of an array, but hasn’t been used for some time, there will still be a RAID superblock on it.
mdadm will warn you if potential member disks already contain RAID superblocks, and you will have to assert that you want to create the array:
# mdadm -C -n2 -l0 /dev/md3 /dev/sd{d,e}1
mdadm: /dev/sde1 appear to be part of a raid array:
level=1 disks=2 ctime=Wed Mar 20 23:17:38 2002 Continue creating array? y
mdadm: array /dev/md3 started.
mkraid also generates a warning when you try to include disks that already have a RAID superblock in a new array, but its safeguards are slightly more obtuse. In the following example, I’ve created a simple /etc/raidtab that defines an array including member disks that I know were part of an array that’s no longer active:
# mkraid /dev/md1
handling MD device /dev/md1 analyzing super-block
disk 0: /dev/sdb1, 17920476kB, raid superblock at 17920384kB
/dev/sdb1 appears to be already part of a raid array -- use -f to force the destruction of the old superblock
mkraid: aborted.
(In addition to the above messages, see the syslog and /proc/mdstat as well for potential clues.)
Because the loss of data is such a drastic error, even using mkraid --force will return a warning. Using mkraid --really-force is the only way to successfully reuse partitions that already contain data and array superblocks. Even after the second warning, a countdown allowing five additional seconds to cancel the order is displayed.
# mkraid --really-force /dev/md1
DESTROYING the contents of /dev/md0 in 5 seconds, Ctrl-C if unsure!
handling MD device /dev/md0 analyzing super-block
disk 0: /dev/sdb1, 17920476kB, raid superblock at 17920384kB disk 1: /dev/sdc1, 17920476kB, raid superblock at 17920384kB disk 2: /dev/sdd1, 17920476kB, raid superblock at 17920384kB
Unfortunately, the extra checks that mdadm and, to a greater degree, mkraid, per-form can become tedious when you’re experimenting with various array configura-tions—especially when you’re forced to wait five seconds each time you reuse disks.
The dd command is useful for erasing the RAID superblock from previously used partitions. To erase the RAID superblock, you will need to know where it’s located.
disk 0: /dev/sdb1, 17920476kB, raid superblock at 17920384kB disk 1: /dev/sdc1, 17920476kB, raid superblock at 17920384kB disk 2: /dev/sdd1, 17920476kB, raid superblock at 17920384kB
The previous output is generated by mkraid when a new array is constructed. In this case, the superblock was written to each disk at block 17920384. The md driver uses a 4 KB block size. Don’t worry about recording the location of the RAID superblock,
because each time an array changes status, this information is reported via syslogd.
That means the superblock location is recorded each time an array is started, stopped, or encounters an error. Look for a syslog entry similar to this one (kern.
info):
Apr 25 11:54:59 jaded kernel: md: sdd1 [events: 00000001]<6>(write) sdd1's sb / offset: 17920384
Apr 25 11:54:59 jaded kernel: md: sdc1 [events: 00000001]<6>(write) sdc1's sb / offset: 17920384
Apr 25 11:54:59 jaded kernel: md: sdb1 [events: 00000001]<6>(write) sdb1's sb / offset: 17920384
Use dd to zero the superblock of each member disk you wish to reuse:
# dd if=/dev/zero of=/dev/sdb1 bs=1k seek=17920384 count=4
Be extremely careful when using dd to erase RAID superblocks or to modify any information on hard disks. If you accidentally specify the wrong device or make a mistake on the command line, you could destroy all data on the disk. When working with dd, if= specifies the input file to use. Data from the input file is written to the output file, specified by of=. In this example, we take input from /dev/zero (a char-acter special file that generates zeros) and write it to /dev/sdb1, which means zeros are written to the output file. bs=1k specifies a block size of 1 KB. That means 1 KB worth of zeros is read from /dev/zero and then written to /dev/sdb1 at a time. seek= specifies how many blocks to advance (also using the 1 KB block size) in the output file. Finally, count=4 tells dd to write only 4 blocks’ worth of data to the output file.
dd performs a seek to block17920384of /dev/sdb1 (using a 1 KB block size) and then writes null bytes (/dev/zero) into each location for the next four blocks.
Repeat this process for each old member disk that you wish to reuse. If you’re experi-menting, it might be useful to create a shell script to help automate this process.
mdadm also provides a mechanism, --zero-superblock, that allows you to removethe RAID superblock from disks that were part of an array. mdadm allows you to remove the superblock from more than one disk at a time:
# mdadm --zero-superblock /dev/sd{b,c}1
Now when you create a new array, you will not be prompted for additional confir-mation before the new array is created. It might seem that going through these steps is more complicated and time-consuming than simply confirming the additional warning messages produced by mkraid and mdadm. This is undeniably true for mdadm, but remember that mkraid forces you to wait an additional five seconds before creating the array. Also, there are other times when it is desirable to remove unwanted RAID superblocks. For example, it’s a good idea to remove the RAID superblock from any disk that’s no longer part of an array. After all, you don’t want
the kernel to inadvertently start an array you are no longer using or consider a disk that should no longer be part of any array, especially when that might mean vital arrays cannot be built because their disks are already in use.