Description of the issue
There is an issue with the new rescan method introduced in PR #294 that the unmount didn't clean up the physical devices.
More detail : In the new cleanup proceduce, we get the multipath devices belonging to the same volume from multipath -ll output, but it happens in ActionAfterDetach, before that, a multipath -f is called, which will remove the volume record from the multipath -ll output. So that we can't get what we want, and the command "echo 1 > /sys/block/sdx/device/delete" won't be called. It will lead to stale info (stale paths in /dev/disk/by-path/) on host.
Description of the optimal solution
Origin order of flex unmount is:
Flush the multipth device: multipath -f mpathx
Unmap the volume from storage
Rescan iscsi session
resan-scsi-bus.sh -r
Change the order of the flex unmount as follow:
Rescan iscsi session if it is a iscsi host
Flush the multipth device: multipath -f mpathx
Remove the devices: echo 1 > /sys/block/sdx/device/delete
Coverage remained the same at 66.484% when pulling 25032d0ffeac37c1c1154b312f0d12ffc4722310 on feature/UB-1941_unmount_fix into 8e7f868b72916540a728ed4fce86d0aaefafc76f on dev.
Description of the issue There is an issue with the new rescan method introduced in PR #294 that the unmount didn't clean up the physical devices. More detail : In the new cleanup proceduce, we get the multipath devices belonging to the same volume from multipath -ll output, but it happens in ActionAfterDetach, before that, a multipath -f is called, which will remove the volume record from the multipath -ll output. So that we can't get what we want, and the command "echo 1 > /sys/block/sdx/device/delete" won't be called. It will lead to stale info (stale paths in /dev/disk/by-path/) on host.
Description of the optimal solution Origin order of flex unmount is:
Change the order of the flex unmount as follow:
This change is