[dm-devel] [PATCH] multipathd: check and cleanup zombie paths
Chongyun Wu
wu.chongyun at h3c.com
Wed Mar 21 01:54:25 UTC 2018
On 2018/3/20 23:14, Bart Van Assche wrote:
> On Tue, 2018-03-20 at 16:12 +0100, Xose Vazquez Perez wrote:
>> On 03/20/2018 03:58 PM, Bart Van Assche wrote:
>>
>>> 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.
>>
>> There are some "remove" flags in rescan-scsi-bus.sh:
>> https://github.com/hreinecke/sg3_utils/blob/d4dbbede04db21c206e4c2acc1cf766117f003c3/scripts/rescan-scsi-bus.sh#L1080
>>
>> -r enables removing of devices [default: disabled]
>> --forceremove: Remove stale devices (DANGEROUS)
>> --forcerescan: Remove and readd existing devices (DANGEROUS)
>
> Last time I checked the rescan-scsi-bus.sh script relied on the SCSI sysfs
> delete attribute to remove stale devices. That is the mechanism that can
> trigger a deadlock in the kernel.
>
> Bart.
>
Hi Bart,
Is there any special operation or conditions to reproduce the dead lock?
I have use SCSI sysfs delete atrribute to remove stale devices in my
previous patch and test many times, but I haven't encountered any
deadlock problems.
Regards,
Chongyun
More information about the dm-devel
mailing list