On Tue, 12 Nov 2013 03:03:44 +0100 (CET) Jan Engelhardt <jeng...@inai.de> wrote:
> > 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? It is easy to do what I describe using ad hoc scripts - that's what I do in the initrd. But for no-root filesystems I don't really want to use some ad-hoc script. I want to integrate into systemd to benefit from all the good bits of systemd. Thanks, NeilBrown
signature.asc
Description: PGP signature
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
