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:
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.
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 localdomain kernel: sd 3:0:1:0: Power-on or device reset occurred
Feb 17 13:05:20 localhost.
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 '360002ac000000 00000000b740000 741c' to '360002ac000000 00000000b750000 741c'
And then reconfigures the old multipath device mapper to remove this device:
Feb 17 13:05:20 localhost. localdomain multipathd[7007]: 360002ac0000000 0000000b7400007 41c: 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] localdomain multipathd[7007]: check_removed_ paths: sdb: freeing path in removed state localdomain multipathd[7007]: 8:16: path removed from map 360002ac0000000 0000000b7400007 41c
Feb 17 13:05:20 localhost.
Feb 17 13:05:20 localhost.
And finally the new device mapper is formed:
Feb 17 13:05:21 localhost. localdomain multipathd[7007]: sda [8:0]: path added to devmap 360002ac0000000 0000000b7500007 41c
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.