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

[Chongyun Wu]

On 2018/3/20 22:58, Bart Van Assche wrote:
> 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.

Hi Bart,

Thank you very much for your advice, I think the two approaches are new 
way for me to clean up stale devices, I will have a try.

Regards,
Chongyun