On Tue, Mar 25, 2025 at 11:33:12PM +0100, Martin Wilck wrote: > 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?
Yep. It's failing in sd_open() -> scsi_block_when_processing_errors() see the comment here: https://github.com/torvalds/linux/blob/5c2a430e85994f4873ea5ec42091baa1153bc731/drivers/scsi/sd.c#L1523 > 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>
