Comment 45 for bug 2004555

I can't reproduce the issue using FC with an HPE 3PAR array, debugging it I found that the compute node receives a signal after the LUN has been remapped (this didn't happen in my iSCSI tests):

 Feb 17 13:05:20 localhost.localdomain kernel: sd 3:0:0:0: Power-on or device reset occurred
 Feb 17 13:05:20 localhost.localdomain kernel: sd 3:0:1:0: Power-on or device reset occurred

This is detected as a "change" in the block device:

  Feb 17 13:05:20 localhost.localdomain systemd-udevd[158430]: 3:0:1:0: /usr/lib/udev/rules.d/60-block.rules:8 ATTR '/sys/devices/pci0000:00/0000:00:05.0/host3/rport-3:0-4/target3:0:1/3:0:1:0/block/sdb/uevent' writing 'change'

Which triggers the code that uses an SCSI command to get the volume's WWID and then updates sysfs to reflect it.

  Feb 17 13:05:20 localhost.localdomain systemd-udevd[158430]: sdb: /usr/lib/udev/rules.d/60-persistent-storage.rules:66 Importing properties from results of 'scsi_id --export --whitelisted -d /dev/sdb'

After that rule another one for multipath is triggered to tell multipathd that it needs to check a device:

  Feb 17 13:05:20 localhost.localdomain systemd-udevd[158430]: sdb: /usr/lib/udev/rules.d/62-multipath.rules:36 Importing properties from results of '/sbin/multipath -u sdb'

Multipathd detects that the WWID has changed (because sysfs has been updated):

  Feb 17 13:05:20 localhost.localdomain multipathd[7007]: sdb: path wwid changed from '360002ac00000000000000b740000741c' to '360002ac00000000000000b750000741c'

And then reconfigures the old multipath device mapper to remove this device:

  Feb 17 13:05:20 localhost.localdomain multipathd[7007]: 360002ac00000000000000b740000741c: reload [0 2097152 multipath 1 queue_if_no_path 1 alua 1 1 service-time 0 3 1 8:0 1 8:48 1 8:32 1]
  Feb 17 13:05:20 localhost.localdomain multipathd[7007]: check_removed_paths: sdb: freeing path in removed state
  Feb 17 13:05:20 localhost.localdomain multipathd[7007]: 8:16: path removed from map 360002ac00000000000000b740000741c

And finally the new device mapper is formed:

  Feb 17 13:05:21 localhost.localdomain multipathd[7007]: sda [8:0]: path added to devmap 360002ac00000000000000b750000741c

I don't know if this is standard FCP behavior or if this is storage array specific and other storage arrays may not behave like this. I'm trying to get access to a different FC array to confirm.