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 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.
Can a distribution set multipath_wwids_file="" by default without
undesired side effects?
Thanks,
Martin
