From: David Teigland <teigland@redhat.com>
To: Heming Zhao <heming.zhao@suse.com>
Cc: Martin Wilck <martin.wilck@suse.com>,
"prajnoha@redhat.com" <prajnoha@redhat.com>,
"zkabelac@redhat.com" <zkabelac@redhat.com>,
"bmarzins@redhat.com" <bmarzins@redhat.com>,
Glass Su <glass.su@suse.com>, "hare@suse.de" <hare@suse.de>,
"linux-lvm@lists.linux.dev" <linux-lvm@lists.linux.dev>
Subject: Re: discuss about commit 3b0f9ce: filter-mpath: get wwids from sysfs vpd_pg83
Date: Tue, 14 Nov 2023 11:16:05 -0600 [thread overview]
Message-ID: <ZVOrVenHY2fowRoE@redhat.com> (raw)
In-Reply-To: <479fc9d6-4677-4df1-b1d8-7ce3be2bb5ae@suse.com>
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
next prev parent reply other threads:[~2023-11-14 17:16 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-11 12:51 discuss about commit 3b0f9ce: filter-mpath: get wwids from sysfs vpd_pg83 Heming Zhao
2023-11-13 11:52 ` Martin Wilck
2023-11-13 13:52 ` Peter Rajnoha
2023-11-13 18:38 ` David Teigland
2023-11-14 7:55 ` Peter Rajnoha
2023-11-14 16:30 ` David Teigland
2023-11-15 8:51 ` Peter Rajnoha
2023-11-15 11:36 ` Heming Zhao
2023-11-15 19:12 ` David Teigland
2023-11-16 13:37 ` Zdenek Kabelac
2023-11-16 13:46 ` Martin Wilck
2023-11-16 14:03 ` Zdenek Kabelac
2023-11-16 15:29 ` Martin Wilck
2023-11-16 17:13 ` David Teigland
2023-11-16 15:10 ` David Teigland
2023-11-16 15:40 ` Martin Wilck
2023-11-16 15:48 ` Zdenek Kabelac
2023-11-16 17:27 ` David Teigland
2023-11-16 15:59 ` Zdenek Kabelac
2023-11-17 1:47 ` Demi Marie Obenour
2023-11-17 15:25 ` David Teigland
2023-11-17 19:57 ` Demi Marie Obenour
2023-11-17 20:16 ` David Teigland
2023-11-17 21:03 ` Demi Marie Obenour
2023-11-17 21:05 ` Martin Wilck
2023-11-20 10:13 ` Zdenek Kabelac
2023-11-15 21:02 ` David Teigland
2023-11-15 21:46 ` Martin Wilck
2023-11-16 16:11 ` David Teigland
2023-11-14 10:44 ` Martin Wilck
2023-11-14 12:18 ` Heming Zhao
2023-11-14 17:16 ` David Teigland [this message]
2023-11-14 17:00 ` David Teigland
2023-11-14 17:48 ` Martin Wilck
2023-11-14 17:58 ` Martin Wilck
2023-11-14 21:02 ` David Teigland
2023-11-15 7:35 ` Martin Wilck
2023-11-16 16:34 ` David Teigland
2023-11-16 20:22 ` Benjamin Marzinski
2023-11-14 20:51 ` David Teigland
2023-11-15 5:15 ` Heming Zhao
2023-11-15 7:39 ` Martin Wilck
2023-11-21 14:39 ` Martin Wilck
2023-11-21 17:56 ` David Teigland
2023-11-21 18:10 ` Martin Wilck
2023-11-21 18:25 ` David Teigland
2023-11-21 20:35 ` Martin Wilck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZVOrVenHY2fowRoE@redhat.com \
--to=teigland@redhat.com \
--cc=bmarzins@redhat.com \
--cc=glass.su@suse.com \
--cc=hare@suse.de \
--cc=heming.zhao@suse.com \
--cc=linux-lvm@lists.linux.dev \
--cc=martin.wilck@suse.com \
--cc=prajnoha@redhat.com \
--cc=zkabelac@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).