linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Martin Wilck <mwilck@suse.com>
To: David Teigland <teigland@redhat.com>,
	Peter Rajnoha <prajnoha@redhat.com>
Cc: LVM general discussion and development <linux-lvm@redhat.com>,
	Heming Zhao <heming.zhao@suse.com>
Subject: [linux-lvm] LVM autoactivation and udev
Date: Wed, 09 Mar 2022 16:29:27 +0100	[thread overview]
Message-ID: <38c190ac39c244d9442670589b7bfeb4f800383e.camel@suse.com> (raw)

Hi David, hi Peter,

we have recently updated LVM2 on openSUSE Factory, and are using the
autoactivation feature now. We also use
'external_device_info_source="udev"' by default, because according to
our experience it is the only way to make LVM device detection work
reliably with multipath devices.

With these settings, we see lots of "Udev database has incomplete
information about device ..." messages:

> [   12.377563] apollon systemd-udevd[810]: sda5: Processing device (SEQNUM=2787, ACTION=add)
> [   12.412723] apollon systemd-udevd[810]: sda5: /usr/lib/udev/rules.d/69-dm-lvm.rules:82 Importing properties from results of '/usr/sbin/lvm pvscan --cache --listvg --checkcomplete --vgonline --autoactivation event --udevoutput --journal=output /dev/sda5'
> [   12.412767] apollon systemd-udevd[810]: sda5: Starting '/usr/sbin/lvm pvscan --cache --listvg --checkcomplete --vgonline --autoactivation event --udevoutput --journal=output /dev/sda5'
> [   12.413041] apollon systemd-udevd[810]: Successfully forked off '(spawn)' as PID 882.
> [   12.419458] apollon lvm[882]: Udev database has incomplete information about device /dev/sda5.

This is no surprise, because 69-dm-lvm.rules contains

IMPORT{program}="/usr/sbin/lvm pvscan --cache --listvg --checkcomplete --vgonline --autoactivation event --udevoutput --journal=output $env{DEVNAME}"
ENV{LVM_VG_NAME_COMPLETE}=="?*", RUN+="/usr/bin/systemd-run --no-block --property DefaultDependencies=no --unit lvm-activate-$env{LVM_VG_NAME_COMPLETE} (LVM_EXEC)/lvm vgchange -aay --autoactivation event $env{LVM_VG_NAME_COMPLETE}"

These rules are executed by udev while it is processing an "add" event
for a PV. At that time, the udev data base doesn't contain an entry for
this PV yet, because the entry is added only after the uevent is fully
processed.

Shouldn't "pvscan" be run in a RUN+= statement instead? Obviously if we
do this, the lvm-activate-$VG unit must be started in some other way
(e.g. by calling systemd-run directly from pvscan).

In the cases we have observed so far, the VGs were assembled correctly
despite these warnings. We aren't certain if this was by luck only. In
any case, the messages irritate users.

Or are we getting this completely wrong, and the new autoactivation
feature should not be used with external_device_info_source="udev" at
all? If that's the case, how is multipath component detection supposed
to work?

Regards,
Martin

_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/


             reply	other threads:[~2022-03-10  7:46 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-09 15:29 Martin Wilck [this message]
2022-03-09 16:27 ` [linux-lvm] LVM autoactivation and udev David Teigland
2022-03-09 17:04   ` Martin Wilck
2022-03-09 17:26     ` David Teigland
2022-03-09 19:48       ` Martin Wilck
     [not found]         ` <1f49866ba907896dc3678b47c5bb68d87e28b3c1.camel@suse.com>
2022-03-09 20:07           ` David Teigland
2022-03-09 17:07   ` Roger Heflin
2022-03-09 17:17     ` Martin Wilck
2022-03-21  8:57 ` heming.zhao
2022-03-21 16:44   ` David Teigland
2022-03-23  7:33     ` heming.zhao
2022-03-23  7:51       ` Martin Wilck
2022-03-24  8:26         ` heming.zhao
2022-03-24  9:02           ` Martin Wilck
2022-03-24 19:01           ` David Teigland

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=38c190ac39c244d9442670589b7bfeb4f800383e.camel@suse.com \
    --to=mwilck@suse.com \
    --cc=heming.zhao@suse.com \
    --cc=linux-lvm@redhat.com \
    --cc=prajnoha@redhat.com \
    --cc=teigland@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).