[lvm-devel] [PATCH] config: set external_device_info_source=none if udev isn't running

David Teigland teigland at redhat.com
Fri Jan 29 16:59:54 UTC 2021


Hi Martin, thanks for the patch, it looked obviously correct on first
glance, but with this discussion perhaps I missed something, so I'll have
to go back and look again.

On Fri, Jan 29, 2021 at 11:07:12AM +0100, Martin Wilck wrote:
> Of course *udev* works "in my main system". But *LVM2* does not: with
> the default setting "external_device_info_source=none", it ignores udev
> properties of devices. This is the source of lots of subtle errors and
> race conditions during device setup. Therefore we changed the setting
> to "udev".
> 
> How do you handle that in Fedora? I took the liberty to look at the
> Fedora 33 package, and it doesn't change default from "none" to
> "udev". So by common sense, Fedora is going to suffer from the same
> general problem that (open)SUSE sees: With "none", lvm can detect
> multipath or MD components only "after the fact", i.e. after multipathd
> or mdadm have grabbed them already. If pvscan and multipathd start up
> simultaneously, it's anyones guess who "wins" (*). With "udev", that
> can't happen, and that's why "udev" should be made the default.

You're right that it's extremely fragile, and we rely on the complex
systemd/udev/rules/etc machinery for all the components to work just
right.  Obviously they often don't (especially with many devices), and
it's a serious headache to sort out what happened, with few options to
actually fix or workaround problems.  In our experience we've managed to
get external=none to work pretty well, although not perfect.  It sounds
like it's not working quite as well in your case, which I'd guess is due
to slight differences in the udev-related machinery.  We usually end up
adjusting udev rules when problems come up.  As Zdenek has mentioned,
there are also issues with external=udev (although we don't have as much
experience to give details).  I don't think external=udev would be a big
improvement, at least in our case.  Given my level of disregard for udev
overall (trying to be polite about that), I now prefer that we do
everything we can natively, without depending on udev.  I think the best
approach is to use native detection *plus* udev info in spots, so we get
all possible info, without relying entirely on udev.  So I think the
answer is to use any/all sources of info that are available at the time we
need it, and not configure one or the other statically.

> (I'm cc'ing Ben Marzinski, as he should know this problem very well,
> and knows Fedora, too).

Quite a while ago I talked with Ben about making lvm read
/etc/multipath/wwids to detect mpath components.  I wrote an initial patch
which I never finished since there wasn't interest.  Now things have
changed, and I also have a new feature (devices file) that will make it
easier to use the mpath wwids.  Ben also mentioned a new library that we
might also look at using to get the the mpath wwids.

Dave




More information about the lvm-devel mailing list