On Fri, 2026-11-06, Martin Wilck wrote:
> You will need convince me that this doesn't do more harm than good.
> We can't just use udev in one place and other methods elsewhere.
>
> I am open for a general redesign that uses sysfs for retrieving
> WWIDs, rather than udev. But using SG_IO seems wrong to me in general,
> because it can hang.
Agreed on SG_IO. v3 drops it: the re-add check compares the udev WWID
with one built from the VPD page 0x83 data cached in sysfs, using the
same get_vpd_uid()/parse_vpd_pg83() code as the existing sysfs
fallback in get_uid(). It does no I/O on the device.
On mixing methods, one thing I should have said earlier: on RHEL 9 the
udev WWID isn't taken from sysfs. The RHEL sg3_utils package installs
55-scsi-sg3_id.rules as 61-scsi-sg3_id.rules ("need to run after
60-persistent-storage.rules"), so ID_SERIAL comes from
"scsi_id --whitelisted", which sends INQUIRY over SG_IO; strace on our
host shows it on every run. The bad WWID came from that INQUIRY.
Where the sg3 rules run first, ID_SERIAL is derived from the same
sysfs page the check reads, with the same designator selection when
everything is at defaults, and can_recheck_wwid() limits the check to
that case. So I'd argue it isn't another way of computing the WWID,
but a comparison of udev's value with the data it is meant to come
from.
I also dropped the uev_update_path() check from v2. With cached data
it could keep a path to a really remapped LUN in its old map, which is
worse than the problem it was meant to fix.
> I wouldn't call this a valid test. It's a deliberate abuse of udev
> functionality.
Fair. The tool doing this is ours, and we've changed it to open the
devices read-only, which stops the flood of change events in our
testing. The reason
I'd still like multipathd to check the re-add is that when it goes
wrong, the result is silent data corruption on another LUN, and
nothing else in the stack notices.
> Thinking about it, I wonder if we should simply set "nowatch" for
> multipath members by default.
I think that's worth doing regardless of this patch, and I'm happy to
look at it separately.
Brian
