All of lore.kernel.org
 help / color / mirror / Atom feed
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 10:59:54 -0600	[thread overview]
Message-ID: <20210129165954.GA7644@redhat.com> (raw)
In-Reply-To: <e45a5da341edd2593dce5ef087039f84c20338f4.camel@suse.com>


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



  parent reply	other threads:[~2021-01-29 16:59 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
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 [this message]
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=20210129165954.GA7644@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.