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
