Re: [PATCH v3 0/1] multipathd: check re-added paths' WWIDs against sysfs

[Brian Bunker <brian@purestorage.com>]

On Wed, 2026-11-11, Martin Wilck wrote:
> Right, but "newer" doesn't mean "more accurate". You write below that
> there is no indication that anything actually changed, so time
> shouldn't be a factor. If a wrong VPD reply is possible once, it can
> also occur multiple times. If it's just an unlikely failure, a purely
> stochastical thing, it would help to simply repeat the same request;
> if the probability for error is 1e-4, the probability for two errors
> in succession would be 1e-8. However we don't know if it's
> stochastical.

Fair, "newer" was the wrong word, and we can't show what caused the bad
reply.

I think the patch stands without that, though. recheck_wwid already
exists to stop a path whose WWID has changed from staying in, or going
into, the wrong map: multipathd checks the WWID with the device when a
failed path comes back, and when a path is added with "multipathd add
path". The re-add in uev_update_path() is a third place where a path is
put into a map because of a WWID change, and the only one of the three
that acts purely on the udev value. v4 applies the same check there,
under the same option.

It also costs little: nothing unless recheck_wwid is set, and with it
set, one INQUIRY on a re-add that only happens after udev reports a
changed WWID. If it ever refuses an add, it logs the udev WWID and the
one the device returned. We'll run with recheck_wwid enabled on our test
initiators and watch for that message. If it shows up more than once,
we'll come back with those logs, which would be better evidence than the
one run we have, where we didn't know at the time that our test tool was
flooding udev.

> I'd go one step further and say that it tells us nothing at all.

Agreed.

> However from the time line you provided, it makes sense that your
> patch would have been effective in the error case.

Thanks.

Brian