linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Martin Wilck <mwilck@suse.com>
To: "heming.zhao@suse.com" <heming.zhao@suse.com>,
	David Teigland <teigland@redhat.com>
Cc: Peter Rajnoha <prajnoha@redhat.com>,
	LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] LVM autoactivation and udev
Date: Wed, 23 Mar 2022 08:51:16 +0100	[thread overview]
Message-ID: <89c9ea9d0a5e04071b5bfc00994332d6f9068438.camel@suse.com> (raw)
In-Reply-To: <a4df63ee-1381-de03-7490-bb1d51fa1e0e@suse.com>

On Wed, 2022-03-23 at 15:33 +0800, heming.zhao@suse.com wrote:
> 
> I inclined to use the "--config" option to avoid booting warning.
> (or write additional codes for vgchange "monitor_ARG")
> 
> I have two reasons:
> 
> 1>
> Martin & I also found it is a difficult to find the best time to
> start lvm2-monitor.service
> So modification "After=" dependency will still failed with some
> cases.

Yes. The reason is that even after "sysinit.target" is reached, "udev
settle" for coldplug hasn't necessarily finished these days (as
systemd-udev-settle.service is deprecated, and often not activated any
more). Thus even if started after sysinit.target, lvm2-monitor.service
may encounter devices that haven't been fully processed by udev yet.

> 2>
> the lvm2-monitor.service helps to finish monitoring job for lvm_scan.
> So it's not necessary
> to ask this service to handle the VG/LV which starting after switch
> rootfs. (These VG/LV
> should be monitored by "pvscan --cache".)
> 
> So starting lvm2-monitor.service as early as possible is accepted.

Please forgive me if I am (out of ignorance about dmeventd) totally on
the wrong track here, but:

I still have my doubts. I can see that the warnings about missing udev
information have gone if we use  --config 'devices {
external_device_info_source="none" }'. But that doesn't mean much by
itself. vgchange will instead rely on native device detection, which,
as we know very well, will lead to wrong results more often than not,
in particular if multipath devices are present. IOW, it will probably
ask dmeventd to monitor SCSI devices that are path of multipath maps,
rather than the map devices themselves. I don't know dmeventd well
enough to judge whether that would be fatal, but past experience makes
me wary about it.

I suppose to test that we'd need to setup systems with root FS on
"monitored" LVM volumes (e.g. thin or mirror) on multipath (with recent
multipath releases, 0.8.8 or newer). I for one haven't tested this so
far.

What I would love to see wrt lvm2 monitoring is true event-based
activation - i.e. activate monitoring of devices one by one as they
actually appear in the system, in a manner that's consistent with udev.
Thus something similar to David's late approach with the "devices file"
for PV detection. That would avoid both the need to pass config options
and the need to figure out when to safely start the monitoring.

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-24 15:35 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-09 15:29 [linux-lvm] LVM autoactivation and udev Martin Wilck
2022-03-09 16:27 ` 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 [this message]
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=89c9ea9d0a5e04071b5bfc00994332d6f9068438.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).