Once a new arrived LUN mapped we will do rescan by "echo '- - -' > /sys/class/scsi_host/host2/scan". After rescan only the scsi_id tool give the right serial id, udevadm still got the prvious one.
I have monitor the udev event by udevadm monitor while mapping a new LUN to the host, who will reuse the original path. No add event is triggerred, only dm-X emits a change event.
But if the original path is deleted(removed) then add event will be triggerred.
Flush the old WWID could make the WWID correct but the size is still incorrect as following. And 36005076300810eadf800000000000155 is actually 5GB.
[root@localhost ~]# multipath -v2
Jul 11 12:36:06 | sdp: using deprecated getuid callout
Jul 11 12:36:06 | sdq: using deprecated getuid callout
create: 36005076300810eadf800000000000155 undef IBM,2145
size=8.0G features='1 queue_if_no_path' hwhandler='0' wp=undef
Jul 11 12:36:06 | sdp: using deprecated getuid callout
Jul 11 12:36:06 | sdq: using deprecated getuid callout
create: 36005076300810eadf800000000000155 undef IBM,2145
size=8.0G features='1 queue_if_no_path' hwhandler='0' wp=undef
I built the tool using latest code and tried both attribute_id and getuid_callout. The issue exist in both configuration.
> Dear list,
> We have a FC storage and using multipathd to manager the FC paths.
> I've met an issue in this environment. The following is how to recreate the issue.
>
> =======
> 1. Map a LUN to host with LUN ID 0,
> 2. rescan fc_host, a new path will be found by multipath.
> 3. Unmap LUN 0. path will failed as following.
> [root@localhost sys]# multipath -ll
> Jul 10 18:41:50 | sdp: couldn't get asymmetric access state
> Jul 10 18:41:50 | sdq: couldn't get asymmetric access state
> 36005076300810eadf800000000000156 dm-3 IBM,2145
> size=8.0G features='2 queue_if_no_path retain_attached_hw_handler' hwhandler='1 alua' wp=rw
> |-+- policy='service-time 0' prio=0 status=enabled
> | `- 2:0:0:0 sdp 8:240 failed faulty running
> `-+- policy='service-time 0' prio=0 status=enabled
> `- 2:0:1:0 sdq 65:0 failed faulty running
> 4. Map another LUN which have different ID_SERIAL but with the same LUN ID(0).
Did you "rescan" the SCSI device via sysfs to let Linux know that this
is now in fact a different device?
AFAIK, Linux decodes SCSI sense data for LUNs remapped on the storage
target and emits a udev event, but I'm not aware of any default udev
rule that would actually react. The kernel itself does not react other
than creating the uevent.
> Multipath(check_path function) will set the paths up, tur checker will successfully test the LUN.
> [root@localhost sys]# /lib/udev/scsi_id --whitelisted --replace-whitespace --device=/dev/mapper/36005076300810eadf800000000000156
> 36005076300810eadf800000000000155
> I think this is not right, although I do not remove the device by 'echo 1> /sys/block/sdp/device/delete'. A multipath is identified by LUN scsi ID, in this situation the multipath
> ID is not equal to LUN scsi ID. And if I add the previous LUN back, the paths will also be added to that multipath id(36005076300810eadf800000000000156).
>
> Any suggestion on how to make it create a new node in /dev with correct scsi ID? Thanks.
If you assume the old mapped volume would be gone, you could also flush
the mpath map with the old WWID.
After the SCSI device rescan it should create a new map with the new WWID.
>
> ===========
> [root@localhost sys]# cat /etc/multipath.conf
> defaults {
> features "0"
> no_path_retry queue
> getuid_callout "/lib/udev/scsi_id --whitelisted --replace-whitespace --device=/dev/%n"
IIRC, using an explicit getuid_callout has been deprecated in later
releases of multipath tools and it would use builtin code to determine
the necessary information, potentially even using inquiry data cached in
the kernel (exported via sysfs).
If your toolchain is recent enough, would it work without this conf setting?
> }
> blacklist {
> devnode "sd[a-m]"
> }
--
Mit freundlichen Gr??en / Kind regards
Steffen Maier
Linux on z Systems Development
IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschaeftsfuehrung: Dirk Wittkopp
Sitz der Gesellschaft: Boeblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
liuqing@xxxxxxxxxx
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
