Re: pvscan --cache -aay $device does not activate LV with multiple "legs"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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/




[Index of Archives]     [Gluster Users]     [Kernel Development]     [Linux Clusters]     [Device Mapper]     [Security]     [Bugtraq]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]

  Powered by Linux