Use case: I have a total of 15 md/raid arrays here, all but one of them duplicated, with a working and backup md of the same size, covering me for fat-fingering as well as physical redundancy. Under normal conditions I not only keep the backup partitions unmounted, but the backup arrays entirely unassembled. Even of the eight working arrays, I only assemble three for ordinary use, and use a script to assemble arrays and mount filesystems, unmount and disassemble, as needed. (One array contains all the portage/layman/kernel trees and sources, for instance. It's only assembled/mounted when I'm updating the system.) Unfortunately, the existing mdraid initscript doesn't work so well for that. All it does is mdadm -As, which scans mdadm.conf and assembles all the arrays it finds there and available on the hardware. The mdadm documentation says <ignore> as the second field of an ARRAY line (in place of the device name) tells mdadm not to auto-assemble those arrays -- only assemble them when they're specifically named on the command line. Unfortunately, that doesn't work as documented when given -As (assemble, scan), and it TRIES to assemble them anyway. But as I have multiple such <ignore> arrays, it simply errors out saying that I have multiple arrays with the same name, failing to assemble *ANY* of them. Semi-fortunately, udev is automated enough these days to serve as a /partial/ solution. When left alone to work with mdadm, it'll ignore the arrays that are configured with <ignore> and only assemble the ones with a proper devicename as field two of the ARRAY line. Thus, if the mdraid start function is stubbed out, set to only return 0 (so it'll register as started and the stop function will be called at shutdown as it should be), leaving things to udev, things will SORT OF work... AS LONG AS it's normal boot/reboot/shutdown, no switching between initlevels (like default) with mdraid and levels (like single-user-mode/initlevel 1) without mdraid. But just try going to single-user-mode and then back to the default runlevel! It won't work, at least not if mdraid is in any level other than sysinit! The initscript is actually broken in two ways. One (initscript failing to actually stop the service if rootfs is on mdraid) is covered in bug #414259 which I just filed. The patch below fixes the one we're dealing with here, no way to specify only specific raid-arrays, not all of them, and mdadm's breakage with -As when <ignore> is used for multiple ARRAY lines in mdadm.conf. The fix is actually quite simple. Add an optional MDS= line and an appropriate comment to /etc/conf.d/mdraid, and add an if/then/else to the initscript itself, testing for the variable and assembling only the arrays it contains if it's non-zero-length, doing the old mdadm -As if the variable doesn't exist or is empty: For /etc/init.d/mdraid's start function: local output ebegin "Starting up RAID devices" - output=$(mdadm -As 2>&1) - eend $? "${output}" + + if [ "$MDS" ] ; then + for md in $MDS; do + output=$(mdadm -A /dev/$md 2>&1) + status=$? + # if the md is already assembled (by udev, etc), + # it'll fail with exit status 2 and null output. + # Don't print that, or success (status 0) + [ "$status" -ne 0 ] && [ "$status" -ne 2 ] && eend $status "${output}" + done + else + output=$(mdadm -As 2>&1) + eend $? "${output}" + fi local pat="/dev/md_d*" set -- ${pat} For /etc/conf.d/mdraid, add something like the following comment/example: # If you wish to start only listed mds, uncomment the # MDS list and modify as necessary. Otherwise we # scan mdadm.conf and start all the mds found. # List just the device names, space separated, # not the full /dev/* paths. #MDS="md4 md7" (Note that as coded above, the MDS var should contain only the device names, not the full /dev/md* path strings. I debated whether to include the /dev/ bit or not, but didn't. If you think it'll be clearer, change accordingly.)
why don't we fix the handling of <ignore> in the config file instead ? patches must be attached. posting them as inline comments leads to them being mangled and useless.
glancing through the code indicates this wasn't fully implemented. so i'll send a bug report to the raid list about it.
handling of multiple <ignore> lines in mdadm.onf (as well as ignoring them during assemble time) will be fixed in the next release
