On Tuesday 2013-11-12 01:31, NeilBrown wrote: > >mdadm is quite good at assembling arrays incrementally. "udev" runs >"mdadm -I" for each new device and mdadm gathers them into arrays and >activates the array once all the expected devices have been gathered. >[mdadm might] wait [...] forever. >mdadm can handle this, but it needs to be told. The command: > mdadm -IRs >will find any arrays which have enough devices to start degraded but haven't >been started yet, and will start them.
Using mdadm -R in udev would be a really bad idea, because it would make for a race, I think. Consider a system that has finished booting and is as ready as can be, and you plug in USB disks that form a RAID array. If you use -R, the array may start before you had the chance to plug them all in, causing the array to start in degraded mode, potentially causing a long resync when all missing devices have been plugged into their sockets. >Alternately, is there some "all devices have been probed, nothing new will >appear unless it is hot-plugged" event. That would be equally useful (and >probably mirrors what hardware-RAID cards do). IIRC, openSUSE had a /etc/init.d/boot.coldplug once upon a time (seems to be 9.3) that acted like what you describe. The order was like udevadm trigger, load static module list, udevadm settle, run mdadm, chroot /realroot, repeat for real root once more. Would that still work? _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
