On Thu, Mar 24, 2022 at 04:26:33PM +0800, heming.zhao@xxxxxxxx wrote: > 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. I'm adding this to the _vgchange_monitoring() function: + init_obtain_device_list_from_udev(0); + init_external_device_info_source(DEV_EXT_NONE); so we won't need to add --config... to vgchange in lvm2-monitor. This means that the vgchange monitor will not use udev, avoiding the warnings and stalls caused when udev is slow and uninitialized. Concerns about lvm commands using native detection, instead of udev info, should be a thing of the past, assuming we're talking about the most recent upstream code. If you still see problems with that please let me know. It shouldn't matter when vgchange --monitor runs, or if it tries to monitor all visible VGs. It would be nice to do it more efficiently, looking only at VGs that are unmonitored, or better looking only at VGs for LVs that use monitoring (it's a wasteful step for many if not most users.) I don't see a good way of doing that at the moment. It would also be nice start the monitoring after most autoactivations are done, to avoid any interference, but again I don't see a good way to do it right now. Dave _______________________________________________ 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/
