On 3/23/22 15:51, Martin Wilck wrote:
On Wed, 2022-03-23 at 15:33 +0800, heming.zhao@xxxxxxxx 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.
Your concern is may right, "vgchange --monirtor y" will call lvmcache_label_scan() to search
active VGs , meanwhile libudev hasn't done on some devs. And then vgchange will output
some warning which can be ignored but may irritate users.
In theory, if "vgchange --monitor y" only handles the VGs which created during initrd phase
can avoid this problem.
- Heming
_______________________________________________
linux-lvm mailing list
linux-lvm@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
