On Tue, Nov 14, 2023 at 08:18:14PM +0800, Heming Zhao wrote:
> 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.
It does help in that case. It's also easier to use than creating filters.
It also largely solves the problem of "duplicate PVs" which appear if a
device is cloned/snapshotted/copied, where lvm can't otherwise know which
one is correct. And the subject of this email is an advantage,
eliminating the problems of multipath/md component detection.
But, I'd say the primary advantage of system.devices is preventing
unexpected/accidental use of PVs that are attached to a system, but not
meant to be used by the system. It seems more common these days for a LUN
to be visible to a host that should not be used by the host. This happens
frequently with LUNs passed to VM's, in which case the host should not be
seeing or using that LUN. In the worst case, the host may actually
autoactivate LVs from a LUN that belongs to a VM, which is also activating
and using those LVs.
> > 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.
As I mentioned in the previous mail, external_device_info_source does not
only apply to multipath, so it's not quite so simple. I'm pretty sure
that a new setting will be necessary, not just a new value, and perhaps
multipath_wwids_file will work for that already?
Dave
