Re: discuss about commit 3b0f9ce: filter-mpath: get wwids from sysfs vpd_pg83

On Mon, Nov 13, 2023 at 02:52:39PM +0100, Peter Rajnoha wrote:
> On 11/13/23 12:52, Martin Wilck wrote:
> > I can't stress enough that this is *the only mechanism* that works
> > correctly. udev serves as central hub to retrieve device properties
> > from, and this is how it ought to be.
> 
> Indeed, that was exactly one of the primary reasons the
> 'external_device_info_source="udev"' was added. Reimplementing other
> subsystem's logic is wrong because there's always some intrinsic logic
> there that may be omitted. Sooner or later, such approach will fail.
> 
> I agree with you here.
> 
> If not sharing information through udev due to various kinds of hatred
> about this part of the system, then alternatively, at least, calling a
> multipath library function from LVM to do the job.

Hi, a number of things haven't been mentioned or noticed:

- In general, it's old versions of lvm that we're discussing here.
Current lvm uses system.devices by default, where none of this is
relevant.  We can just turn off a number of filters when system.devices is
in use, including filter-mpath and filter-md.  It may still be interesting
to look at improvements, but the context for that is older stable,
released versions.

- In RHEL8 (no system.devices by default, and some older systemd/udev),
lvm can't touch udev without causing timeouts booting with many devices.
Nothing I tried apart from reading wwids would help.  Boot timeouts were a
big support burden, and the motivation for the changes.  (All of this
added motivation for system.devices.)

- I tried many things before reading wwids, including asking for a
multipath lib API for reading the wwids.  The provided API that I tried
also used udev, so it was no better.  I'd still prefer to use an API to
check a wwid and avoid reading /etc/multipath/wwids directly.  Reading
wwids looked like the least worst practical solution.  I consider it a
temporary hack/workaround until system.devices eliminates the issue.

- When making the changes to avoid udev by default, I made a subtle change
to the meaning of external_device_info_source=udev.  I made that info
supplementary to the native info rather than an alternative to the native
info.  The idea was: why not use all the info we have available?  However,
for filter-mpath, the supplementary approach will be a problem if reading
wwids gives a false positive.

- To make filter-mpath use udev info, and prevent lvm from using wwids,
you can set external_device_info_source=udev and multipath_wwids_file="".
I think this will be an effective way to avoid any false positive
problems from native detection.

Dave