On Mon, 2025-03-24 at 16:55 -0400, Benjamin Marzinski wrote: > If a multipath device was created by the multipath command, > multipathd > might not agree with how the device was created. ev_add_map() can > reload > the device with a different table by calling add_map_without_path() - > > > update_map(). If this reloading of the map failed, multipathd was > simply > ignoring the multipath device, even though it still existed. > > One way that reloading can fail is if a path that multipathd already > has > initialized goes offline. If a multipath device is created by the > multipath command while the path is offline, it will not use the > offline > path, since multipath won't be able to get the necessary pathinfo. > However, multipathd will already have the pathinfo for the path, and > may > not even know that it's offline, since the path is an orphan. When it > tries to reload the device, it will include the offline path, and the > reload will fail.
Am I understanding correctly that during the reload, bdev_open() failed in the kernel because the path was offline? I was thinking about my recent tests [1] where I'd come to the conclusion that reload failure is hardly possible. While I'd realized that "trying to add a path device that was not previously mapped" might fail, I didn't think of the scenario you describe here. [1] https://lore.kernel.org/dm-devel/ee6fcbda31fd1f13969653782417fbed748f5bc7.ca...@suse.com/ > > Instead of ignoring the device if it can't reload it, multipathd > should > just montior it as it is. When the path device is no longer offline, > it > can be added back to the multipath device by calling > "multipathd reconfigure" or "multipathd add path <path>". > Signed-off-by: Benjamin Marzinski <bmarz...@redhat.com> Reviewed-by: Martin Wilck <mwi...@suse.com>
