[dm-devel] 'multipath add path' returns ok but the path is missing in the topology

[Gioh Kim]

Hi Martin,

On Wed, Apr 22, 2020 at 12:05 PM Martin Wilck <mwilck at suse.com> wrote:
>
> 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).
Ok, I will run tests again and send you logs later.
I am using 0.6.4 for Debian stretch.

>
> 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
>
>

One question.
Is it possible for multipathd to generate an event for removing a map?
I am looking into the source code, ev_add_path and some functions
related to add a path,
but it looks like it does not generate any event.

Thank you again for your reply.

-- 
Gioh Kim

Cloud server kernel maintainer
Quality Management (IONOS Cloud)

1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Germany
Phone: +49 176 26978962
E-mail: gi-oh.kim at cloud.ionos.com | Web: www.ionos.de

Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498

Vorstand: Dr. Christian Böing, Hüseyin Dogan, Dr. Martin Endreß,
Hans-Henning Kettler, Arthur Mai, Matthias Steinberg, Achim Weiß
Aufsichtsratsvorsitzender: Markus Kadelke

Member of United Internet

Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte
Informationen enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat
sind oder diese E-Mail irrtümlich erhalten haben, unterrichten Sie
bitte den Absender und vernichten Sie diese E-Mail. Anderen als dem
bestimmungsgemäßen Adressaten ist untersagt, diese E-Mail zu
speichern, weiterzuleiten oder ihren Inhalt auf welche Weise auch
immer zu verwenden.

This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient of this e-mail, you are hereby
notified that saving, distribution or use of the content of this
e-mail in any way is prohibited. If you have received this e-mail in
error, please notify the sender and delete the e-mail.