[dm-devel] [PATCH] multipathd: check and cleanup zombie paths

Bart Van Assche Bart.VanAssche at wdc.com
Tue Mar 20 14:58:08 UTC 2018


On Tue, 2018-03-20 at 03:19 +0000, Chongyun Wu wrote:
> Actually there are two scenario:
> (1)Export the LUN to a server at the same time using different LUN nubmer.
> As you mentioned this scenario can be considered a misconfiguration 
> which we might not care about it.
> (2)Export the LUN to a server not at the same time using different LUN 
> number.
> This scenario's operation may be right, the customer just want to 
> reassignment the export relations in the storage.
> But the former export operation leave a residual device in the system 
> which will been adopted by the latter exported device's multipath. Also 
> there are lots of syslog for the former device which actually not 
> exist(at lest customer don't think it exists, the customer want only the 
> new exported device exist)

Hello Chongyun,

It is on purpose that the SCSI core does not remove stale SCSI device nodes.
If you want that these stale SCSI device nodes get removed automatically,
two possible approaches are (there might be other approaches):
* Write a new user space daemon that periodically checks for stale devices
  (e.g. by running grep -aH . /sys/class/scsi_device/*/*/state |
   grep -v running) and that triggers a SCSI rescan if any stale devices are
  found.
* Write a udev rule that listens for SDEV_UA=REPORTED_LUNS_DATA_HAS_CHANGED
  and that triggers a SCSI rescan if this event is triggered by the kernel.

Bart.






More information about the dm-devel mailing list