Re: [PATCH 0/8] multipath fixes to tableless device handling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Nov 07, 2024 at 07:02:11PM +0100, Martin Wilck wrote:
> On Thu, 2024-11-07 at 12:43 -0500, Benjamin Marzinski wrote:
> > On Thu, Nov 07, 2024 at 01:20:09PM +0100, Martin Wilck wrote:
> > > 
> > > Thinking about it, I believe we should actually accept devices that
> > > have an mpath UUID and an empty table, and add them to our mpvec.
> > > We
> > > should treat them like devices that have a multipath target but no
> > > path
> > > devices. If any matching paths become available, the map will be
> > > reloaded and the issue will be fixed. IMO, this is less prone to
> > > race
> > > conditions than trying to delete and re-add the devices.
> > 
> > I'm not sure off the top of my head how easy it will be to handle
> > devices with no dm table at all, but I'll take a look into this.
> 
> I tried this on a system with 0.9.9 yesterday. 0.9.9 will not add the
> map into the mpvec. But in coalesce_paths(), it will just reload the
> map:

Given that the code already does the right thing without needing any
changes to handle tableless maps makes me feel like just removing the
final patch is the best idea.

The only issue with the current code is that if you have a device with
no table with the UUID of a multipath device but a different name than
that multipath device should have, multipath will try to create a new
device instead of reload it, and this fails, since the UUID is already
in use.

That should probably be handled by making the multipath code pay more
attention to the device UUID and less to the device name, but that's
work for a different patchset. 

-Ben

> 
> multipathd[3198]: 360014053cdf4a9b80de42ab96c74f4ef: set ACT_CREATE (map does not exist)
> multipathd[3198]: 360014053cdf4a9b80de42ab96c74f4ef: map already present
> multipathd[3198]: 360014053cdf4a9b80de42ab96c74f4ef: reload [0 41943040 multipath 1 queue_if_no_path 1 alua 2 1 service-time 0 1 1 8:16 1 serv>
> 
> Note that it first says "map does not exist", and then sees it present (with no table).
> The reload works without issues though, if the map is empty.
> 
> If, on the contrary, the map is not empty but contains another incompatible target
> (I tried this with a trivial linear mapping), the reload operation will fail:
> 
> multipathd[1347]: 360014053cdf4a9b80de42ab96c74f4ef: set ACT_CREATE (map does not exist)
> multipathd[1347]: 360014053cdf4a9b80de42ab96c74f4ef: map already present
> multipathd[1347]: 360014053cdf4a9b80de42ab96c74f4ef: reload [0 41943040 multipath 1 queue_if_no_path 1 alua 2 1 service-time 0 1 1 8:16 1 serv>
> kernel: device-mapper: ioctl: can't change device type (old=1 vs new=2) after initial table load.
> multipathd[1347]: libdevmapper: ioctl/libdm-iface.c(1998): device-mapper: reload ioctl on 360014053cdf4a9b80de42ab96c74f4ef  failed: Invalid argument
> multipathd[1347]: dm_addmap: libdm task=1 error: Invalid argument
> multipathd[1347]: 360014053cdf4a9b80de42ab96c74f4ef: domap (0) failure for create/reload map
> multipathd[1347]: 360014053cdf4a9b80de42ab96c74f4ef: removing map
> 
> Regards
> Martin





[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux