[dm-devel] Multipath ID not equal to LUN scsi ID

[liuqing at huayun.com]

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 at 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). Multipath(check_path function) will set the paths up, tur checker will successfully test the LUN. 
[root at 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.


===========
[root at 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"
}
blacklist {
    devnode "sd[a-m]"
}



liuqing at huayun.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20170710/90f0b13d/attachment.htm>