| Newsgroups |
gmane.linux.lvm.general |
| Message-ID |
<[email protected]> |
On 3/23/22 15:51, Martin Wilck wrote:
> On Wed, 2022-03-23 at 15:33 +0800, [email protected] 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
[email protected]
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/