On Sun, Jun 27, 2021 at 09:01:43PM +0800, Tom Yan wrote: > [tom@archlinux ~]$ sudo pvscan --cache -aay /dev/sdb > pvscan[2066] PV /dev/sdb online, VG green is complete. > pvscan[2066] VG green skip autoactivation. The "skip autoactivation" means that the VG has already been activated by a prior pvscan, so it's not being activated again. This state is kept in /run/lvm/vgs_online/<vgname>. The files under /run need to be cleared by reboot. The first pvscan to activate the VG creates that temp file (during startup there's often a race among multiple pvscans to activate the same VG, and the temp file ensures that only one of them does it.) > So is this some kind of bug/regression? Or is it intended for some > reason? What I expect would be, when the command is run with any of > the legs of such an LV as the device, it will check whether all legs > of it are available and if so, the LV will be activated. The files under /run/lvm/pvs_online/ record which PVs have appeared during startup; they are created by the pvscan for each device. pvscan uses these to know when the VG is complete and the LVs can be activated. To test this out manually, remove all the files in pvs_online and vgs_online, and run pvscan --cache -aay $dev for each device in your VG. You should find that the final pvscan will activate the VG. 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/