From: David Teigland <teigland@redhat.com>
To: lvm-devel@redhat.com
Subject: [PATCH] config: set external_device_info_source=none if udev isn't running
Date: Fri, 29 Jan 2021 11:34:44 -0600 [thread overview]
Message-ID: <20210129173444.GB7644@redhat.com> (raw)
In-Reply-To: <968c9f098c342091aa041a61caadcffb3e2434d4.camel@suse.com>
On Fri, Jan 29, 2021 at 02:02:11PM +0100, Martin Wilck wrote:
> LVM filters are hard to get right, even for experienced admins. Not
> because of the regexes, but because of the many different names under
> which devices appear under /dev. Telling admins that they need to
> fiddle with filter rules just to make multipath work sounds like
> something I'd have said 10 years ago, but not in 2021.
I agree.
> > There will be also a new 'filtering' introduced in a form a basic
> > acceptance
> > list of devices - that may be seen in some cases as more simple to
> > use.
>
> Perhaps this will improve matters, perhaps it'll add more confusion.?
> I don't know enough to tell.
The filter problems, among many others, were the motivation to create a
new feature "devices file" which I'm planning to merge into lvm soon.
Latest devel branch (see latest -N suffix):
https://sourceware.org/git/?p=lvm2.git;a=shortlog;h=refs/heads/dev-dct-devicesid-22
The basic idea is that a new lvm config file (the devices file) lists the
devices that lvm can use, and lvm will not even look at devices outside
that list. So the user tells lvm which devices it should use, and that's
all lvm sees. (With an optional allowance for pvcreate to implicitly mean
"use this device", to make it easier for people to begin using this.)
The devices are primarily identified by a WWID, or other similar
identifier. lvm commands are used manage that file, but it can be
manually edited also. It replaces filters, and will make a number of hard
problems in lvm just go away: the problem of unstable dev names in
filters goes away, mpath/md component detection goes away (you wouldn't
include component devs in the device file), the system mistakenly
activating PVs belonging to VMs goes away.
This is obviously not an immediate solution to the problems you're having,
but it's what we have in mind as the best solution, available fairly soon.
For immediate fixes I still think native detection supplemented with udev
or other info is ideal. Don't feel constrained by the old definitions of
config settings - those config settings can be superceded by new ones.
The new devices file code, even when the devices file is not enabled, will
make it easier to consume /etc/multipath/wwids (since the devices file is
using wwids itself). So we can begin improving mpath component detection
before users enable the devices file.
Dave
next prev parent reply other threads:[~2021-01-29 17:34 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-27 17:28 [PATCH] config: set external_device_info_source=none if udev isn't running mwilck
2021-01-28 10:10 ` Zdenek Kabelac
2021-01-28 10:27 ` Martin Wilck
2021-01-28 22:56 ` Zdenek Kabelac
2021-01-29 0:41 ` heming.zhao
2021-01-29 10:07 ` Martin Wilck
2021-01-29 11:11 ` Zdenek Kabelac
2021-01-29 13:02 ` Martin Wilck
2021-01-29 16:38 ` Zdenek Kabelac
2021-01-29 17:58 ` Martin Wilck
2021-01-29 20:36 ` Zdenek Kabelac
2021-01-29 17:34 ` David Teigland [this message]
2021-01-29 19:58 ` Martin Wilck
2021-01-29 20:39 ` David Teigland
2021-01-29 20:43 ` Martin Wilck
2021-01-29 16:59 ` David Teigland
2021-01-29 18:13 ` 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=20210129173444.GB7644@redhat.com \
--to=teigland@redhat.com \
--cc=lvm-devel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.