Re: 'multipath add path' returns ok but the path is missing in the topology

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

 



Hello Gioh,

On Wed, 2020-04-22 at 10:40 +0200, Gioh Kim wrote:
> Hi,
> 
> I would like to report a bug.
> I am using network storage via SRP/SRPT over Infiniband.
> When a new sd device is created by SRP, I execute 'multipathd add
> path
> sdX' command and then a new map device is created automatically.
> 
> I used to use the kernel 4.14 version and had no problem.
> But after upgrading to kernel 4.19, I have a problem that 'multipath
> add path sdX' returns ok but sdX is not included in the topology.
> 
> For example, I ran 'multipath add path sdaj' and 'multipath add path
> sdak' and they returned ok.
> Then I check the topology with 'multipathd show topology' and sdak is
> missing.
> 
> Following is the log message from multipathd daemon.
> I found that
> 1. adding sdaj was done correctly and map
> 3600144f033337cfc3ca5222200196002 and dm-11 was created
> 2. daemon started adding sdak (according to "sdak: add path
> (operator)" message)
> 3. suddenly map dm-11 was removed and created
> 4. adding sdak returned ok but there was no "sdak: path added to
> devmap .." message.  I waited some minutes but it did not show up.
> I guess there would be some corner case for error handling.
> The multipathd might have an error but not return an error.
> 
> 
> <log message>
> multipathd[1920]: sdaj: add path (operator)
> multipathd[1920]: 3600144f033337cfc3ca5222200196002: load table [0
> 2105344 multipath 1 retain_attached_hw_handler 0 1 1 service-time 0 1
> 1 66:48 1]
> multipathd[1920]: 3600144f033337cfc3ca5222200196002: event checker
> started
> multipathd[1920]: sdaj [66:48]: path added to devmap
> 3600144f033337cfc3ca5222200196002
> multipathd[1920]: sdak: add path (operator)
> multipathd[1920]: dm-11: remove map (uevent)
> multipathd[1920]: 3600144f033337cfc3ca5222200196002: stop event
> checker thread (139976177456896)
> multipathd[1920]: dm-11: remove map (uevent)
> multipathd[1920]: 3600144f033337cfc3ca5222200196002: adding map
> multipathd[1920]: 3600144f033337cfc3ca5222200196002: event checker
> started
> multipathd[1920]: 3600144f033337cfc3ca5222200196002: devmap dm-11
> registered
> 
> <multipathd show topology>
> 3600144f033337cfc3ca5222200196002 dm-11 SCST_BIO,e21f6f605c1dfff7
> size=1.0G features='1 retain_attached_hw_handler' hwhandler='0' wp=ro
> `-+- policy='service-time 0' prio=1 status=enabled
> `- 7:0:0:489 sdaj 66:48  active ready running
> 

These logs indicate that multipathd actually successfully added sdak to
the map, so the success return status was correct. The logs provide no
clue why the map was removed and re-added. multipathd seems to have had
just a passive role here. We would need the kernel and udev logs
(udev.log-priority=debug) to see what's actually going on. Also, please
provide your multipath configuration and the version of multipath-tools 
you're using, and logs extending over a long period of time (at least
covering the addition of the new paths).

I'd expect new paths to be added to maps automatically, but that
doesn't seem to happen in your configuration. Are you using
"find_multipaths=strict"? In that case, you should rather use
"multipathd add map "$wwid", or, even better "multipath -a $WWID".

Regards
Martin



--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel




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

  Powered by Linux