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

On 11/14/23 18:44, Martin Wilck wrote:
> On Mon, 2023-11-13 at 12:38 -0600, David Teigland wrote:
>> 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.
> 
> I haven't looked into "system.devices" so far. Is there a high-level
> description of this feature available somewhere? A link would be
> appreciated. On (open)SUSE, afaik, system.device is not used (Heming,
> correct me if I am wrong).

In my view, the system.device was introduced by fixing huge number (>1K)
devices booting timeout issue, which we also discussed 2 or 3 years ago.
Relative to the old methods (event/direct activation), the lvm2 maintainers
hope to use system.device unifying the lvm2 boot code.

In open(SUSE), by default, if the user does not specifically request it,
we do not encourage the user to use system.device. Because we think
system.device is a new feature, it is necessary to wait for a period of time
before recommending it to customers.

> 
>> - 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.)
> 
> We used to see such phenomena, too, but haven't seen them any more
> since SLE15-SP4 (~1.5y). Perhaps the most important change at the time
> was to start multipathd early, before udev, during boot rather than
> waiting for "udevadm settle". But there have been lots of updates in
> the various components involved (see list in my last post), so that's
> just a guess.
> 
>> - 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.
> 
> Good to know, but that's kind of counter-intuitive. I'd prefer
> if external_device_info_source=udev did what the name says, and a new
> mode ("external_device_info_source=hybrid", say) was introduced for the
> current behavior.

Yes, hybird is more suitable option value. Obviously, the current mpio filter
behavior is not compatible with the previous one. the udev is not enough
to describe.

Thanks,
Heming