[dm-devel] multipath-tools 0.7.4 failure to remove device

[Benjamin Marzinski]

Just a bit more information about how RedHat works with multipath
claiming devices in a find_multipaths setup.

Clearly, if you have a multipathed root device, it should be in the
wwids file from the time of installation. So, multipath will
automatically claim it right away when "-i" isn't used. This should
always work fine. But like I mentioned, there is a race when new storage
is added. If that new storage is discovered in the initramfs, the race
can happen there during boot.

When -i isn't used in udev this race isn't as bad.  Usually multipathd
will lose the race to autoassemble on the device, since it can't start
until the second path has been discovered, and lvm/md can start right
away. This means that the wwid will never get in the wwids file, so
multipath will never claim any of the paths, and lvm/md will get
assembled on one path. However if multipathd wins the race and it's
close to a tie, there's a chance that lvm/md will be trying to
autoassemble on the device, and will fail because mutipath just did (or
possibly because the partition devices were removed out from under it).

Now, I don't see how this could cause a boot to fail since this is a new
device that isn't getting set up, but I really never test this, because
when we create the initramfs in RedHat based distros, we edit the
multipath.conf file in it to blacklist all devices except those needed
by the initramfs. This means that we never discover new devices in the
initramfs. In fact, we don't multipath any devices unnecessary for
booting in the initramfs. So, while I can't see a way for this new
device race to cause boot to fail when -i isn't used in udev, I must
admit that we just exclude that from ever happening, so I can't say for
certain that it would always work. Of course it's simple to avoid the
possibility of this race in the initramfs, even without editting
multipath.conf. You just start multipathd with -n in the initramfs.

-Ben