From: Martin Wilck <martin.wilck@suse.com>
To: "teigland@redhat.com" <teigland@redhat.com>
Cc: Heming Zhao <heming.zhao@suse.com>,
"zkabelac@redhat.com" <zkabelac@redhat.com>,
Glass Su <glass.su@suse.com>,
"bmarzins@redhat.com" <bmarzins@redhat.com>,
"hare@suse.de" <hare@suse.de>,
"prajnoha@redhat.com" <prajnoha@redhat.com>,
"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 17:48:45 +0000 [thread overview]
Message-ID: <38458148cb14bf398aa3c6912842ddda79b81115.camel@suse.com> (raw)
In-Reply-To: <ZVOnoCjNmOYToBpt@redhat.com>
On Tue, 2023-11-14 at 11:00 -0600, David Teigland wrote:
> On Tue, Nov 14, 2023 at 10:44:02AM +0000, Martin Wilck wrote:
> > 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).
>
> https://man7.org/linux/man-pages/man8/lvmdevices.8.html
>
> If that's too low-level let me know and I'll look at writing
> something
> more conceptual and introductory.
It looks allright.
"If the system devices file does not yet exist, the pvcreate or
vgcreate commands will create it if they see no existing VGs on
the system."
That basically means that every new installation (where PVs and VGs
will usually have to be created first) will use system.devices, and
thus disable use of filtering and traditional-style multipath component
detection. Right?
And if a user wanted to use the traditional way of determining devices,
she would need to delete the system.devices file?
> > > - 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="".
> >
> > 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.
>
> I'd also thought about adding a new option for
> external_device_info_source
> that would mean "udev info only", rather than "both native and udev
> info."
>
> The complication is that external_device_info_source applies to a few
> different kinds of device info, not just multipath, and I doubt we
> can
> apply only udev info to all those cases.
AFAICS the other use case is MD RAID, no? I think that LVM could rely
on udev for that as well.
> This means adding another config
> option... not much different from just using multipath_wwids_file="".
For multipath, external_device_info_source=udev used to mean "udev
only" until recently, unless I'm mistaken. The semantics of this
settings has changed. I don't know what the situation was for MD or
possible other subsystems. I'm fine with calling the algorithm "udev"
if the respective semantics are still the same that used to be called
"udev" in the past.
> > Can a distribution set multipath_wwids_file="" by default without
> > undesired side effects?
>
> Yes, it just causes lvm to skip the use of /etc/multipath/wwids for
> checking if a device is a multipath component.
Thanks. I'm still not happy about it, but if we find no other solution,
I guess it will be ok.
Regards,
Martin
next prev parent reply other threads:[~2023-11-14 17:48 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
2023-11-14 17:00 ` David Teigland
2023-11-14 17:48 ` Martin Wilck [this message]
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=38458148cb14bf398aa3c6912842ddda79b81115.camel@suse.com \
--to=martin.wilck@suse.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=prajnoha@redhat.com \
--cc=teigland@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).