* [linux-lvm] pvscan --cache -aay $device does not activate LV with multiple "legs" @ 2021-06-27 13:01 Tom Yan 2021-06-28 15:08 ` David Teigland 0 siblings, 1 reply; 5+ messages in thread From: Tom Yan @ 2021-06-27 13:01 UTC (permalink / raw) To: linux-lvm Hi, I notice that LV with multiple legs (i.e. type raid or similar) is not auto activated after boot. After finding out that the activation of LVs mainly relies on lvm2-pvscan@.service (and the udev rules that make the PVs want their own instances), wondering whether the issue is due to a race condition or so, I run the command `pvscan --cache -aay $device` (where $device is in the form of $major:$minor). It seems that it's simply because the device-specific run of the command will not activate such LV(s) anyway: [tom@archlinux ~]$ sudo lvchange -an /dev/green/meh [tom@archlinux ~]$ sudo lvs | grep meh meh green rwi---r--- 512.00m [tom@archlinux ~]$ sudo pvscan --cache -aay /dev/sda2 pvscan[2064] PV /dev/sda2 online, VG green is complete. pvscan[2064] VG green skip autoactivation. [tom@archlinux ~]$ sudo pvscan --cache -aay /dev/sdb pvscan[2066] PV /dev/sdb online, VG green is complete. pvscan[2066] VG green skip autoactivation. [tom@archlinux ~]$ sudo lvs | grep meh meh green rwi---r--- 512.00m However, if I run the command without a device specified, such LV will be activated: [tom@archlinux ~]$ sudo pvscan --cache -aay pvscan[2071] PV /dev/sda2 online, VG green incomplete (need 1). pvscan[2071] PV /dev/sdb online, VG green is complete. pvscan[2071] VG green run autoactivation. 5 logical volume(s) in volume group "green" now active [tom@archlinux ~]$ sudo lvs | grep meh meh green rwi-a-r--- 512.00m 100.00 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. Regards, Tom _______________________________________________ linux-lvm mailing list linux-lvm@redhat.com https://listman.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [linux-lvm] pvscan --cache -aay $device does not activate LV with multiple "legs" 2021-06-27 13:01 [linux-lvm] pvscan --cache -aay $device does not activate LV with multiple "legs" Tom Yan @ 2021-06-28 15:08 ` David Teigland 2021-06-28 16:47 ` Tom Yan 0 siblings, 1 reply; 5+ messages in thread From: David Teigland @ 2021-06-28 15:08 UTC (permalink / raw) To: Tom Yan; +Cc: linux-lvm 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@redhat.com https://listman.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [linux-lvm] pvscan --cache -aay $device does not activate LV with multiple "legs" 2021-06-28 15:08 ` David Teigland @ 2021-06-28 16:47 ` Tom Yan 2021-06-28 17:25 ` Tom Yan 0 siblings, 1 reply; 5+ messages in thread From: Tom Yan @ 2021-06-28 16:47 UTC (permalink / raw) To: David Teigland; +Cc: linux-lvm Well, it doesn't really change the game: [root@archlinux ~]# rm /run/lvm/pvs_online/* [root@archlinux ~]# lvs | grep meh meh green rwi---r--- 512.00m [root@archlinux ~]# pvscan --cache -aay 8\:2 pvscan[36958] PV /dev/sda2 online, VG green incomplete (need 1). [root@archlinux ~]# pvscan --cache -aay 8\:16 pvscan[36959] PV /dev/sdb online, VG green is complete. pvscan[36959] VG green skip autoactivation. [root@archlinux ~]# rm /run/lvm/pvs_online/* [root@archlinux ~]# pvscan --cache -aay 8\:16 pvscan[36964] PV /dev/sdb online, VG green incomplete (need 1). [root@archlinux ~]# pvscan --cache -aay 8\:2 pvscan[36965] PV /dev/sda2 online, VG green is complete. pvscan[36965] VG green skip autoactivation. [root@archlinux ~]# lvs | grep meh meh green rwi---r--- 512.00m Regards, Tom On Mon, 28 Jun 2021 at 23:08, David Teigland <teigland@redhat.com> wrote: > > 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@redhat.com https://listman.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [linux-lvm] pvscan --cache -aay $device does not activate LV with multiple "legs" 2021-06-28 16:47 ` Tom Yan @ 2021-06-28 17:25 ` Tom Yan 2021-06-28 17:52 ` Tom Yan 0 siblings, 1 reply; 5+ messages in thread From: Tom Yan @ 2021-06-28 17:25 UTC (permalink / raw) To: David Teigland; +Cc: linux-lvm Hi again, I just noticed that, `pvscan --cache -aay $device` does work as expected if I remove `/run/lvm/vgs_online/green`. I still couldn't figure out why it doesn't work on boot though. (I do notice that Arch by default uses the "legacy" way (run the pvscan commands with a udev rule RUN directly; but that does not explain the problem either.) So are there any circumstances that vg(s) will be populated into /run/lvm/vgs_online/ without all the "legs" being up? Or circumstances that only the non-multi-leg LVs will be activated? Regards, Tom On Tue, 29 Jun 2021 at 00:47, Tom Yan <tom.ty89@gmail.com> wrote: > > Well, it doesn't really change the game: > > [root@archlinux ~]# rm /run/lvm/pvs_online/* > [root@archlinux ~]# lvs | grep meh > meh green rwi---r--- 512.00m > [root@archlinux ~]# pvscan --cache -aay 8\:2 > pvscan[36958] PV /dev/sda2 online, VG green incomplete (need 1). > [root@archlinux ~]# pvscan --cache -aay 8\:16 > pvscan[36959] PV /dev/sdb online, VG green is complete. > pvscan[36959] VG green skip autoactivation. > [root@archlinux ~]# rm /run/lvm/pvs_online/* > [root@archlinux ~]# pvscan --cache -aay 8\:16 > pvscan[36964] PV /dev/sdb online, VG green incomplete (need 1). > [root@archlinux ~]# pvscan --cache -aay 8\:2 > pvscan[36965] PV /dev/sda2 online, VG green is complete. > pvscan[36965] VG green skip autoactivation. > [root@archlinux ~]# lvs | grep meh > meh green rwi---r--- 512.00m > > Regards, > Tom > > On Mon, 28 Jun 2021 at 23:08, David Teigland <teigland@redhat.com> wrote: > > > > 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@redhat.com https://listman.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [linux-lvm] pvscan --cache -aay $device does not activate LV with multiple "legs" 2021-06-28 17:25 ` Tom Yan @ 2021-06-28 17:52 ` Tom Yan 0 siblings, 0 replies; 5+ messages in thread From: Tom Yan @ 2021-06-28 17:52 UTC (permalink / raw) To: David Teigland; +Cc: linux-lvm Hi again(x2), Never mind, I figured it out: https://bugs.archlinux.org/task/71385 Sorry for the noise. Regards, Tom On Tue, 29 Jun 2021 at 01:25, Tom Yan <tom.ty89@gmail.com> wrote: > > Hi again, > > I just noticed that, `pvscan --cache -aay $device` does work as > expected if I remove `/run/lvm/vgs_online/green`. I still couldn't > figure out why it doesn't work on boot though. (I do notice that Arch > by default uses the "legacy" way (run the pvscan commands with a udev > rule RUN directly; but that does not explain the problem either.) > > So are there any circumstances that vg(s) will be populated into > /run/lvm/vgs_online/ without all the "legs" being up? Or circumstances > that only the non-multi-leg LVs will be activated? > > Regards, > Tom > > On Tue, 29 Jun 2021 at 00:47, Tom Yan <tom.ty89@gmail.com> wrote: > > > > Well, it doesn't really change the game: > > > > [root@archlinux ~]# rm /run/lvm/pvs_online/* > > [root@archlinux ~]# lvs | grep meh > > meh green rwi---r--- 512.00m > > [root@archlinux ~]# pvscan --cache -aay 8\:2 > > pvscan[36958] PV /dev/sda2 online, VG green incomplete (need 1). > > [root@archlinux ~]# pvscan --cache -aay 8\:16 > > pvscan[36959] PV /dev/sdb online, VG green is complete. > > pvscan[36959] VG green skip autoactivation. > > [root@archlinux ~]# rm /run/lvm/pvs_online/* > > [root@archlinux ~]# pvscan --cache -aay 8\:16 > > pvscan[36964] PV /dev/sdb online, VG green incomplete (need 1). > > [root@archlinux ~]# pvscan --cache -aay 8\:2 > > pvscan[36965] PV /dev/sda2 online, VG green is complete. > > pvscan[36965] VG green skip autoactivation. > > [root@archlinux ~]# lvs | grep meh > > meh green rwi---r--- 512.00m > > > > Regards, > > Tom > > > > On Mon, 28 Jun 2021 at 23:08, David Teigland <teigland@redhat.com> wrote: > > > > > > 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@redhat.com https://listman.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/ ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-06-28 17:53 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-06-27 13:01 [linux-lvm] pvscan --cache -aay $device does not activate LV with multiple "legs" Tom Yan 2021-06-28 15:08 ` David Teigland 2021-06-28 16:47 ` Tom Yan 2021-06-28 17:25 ` Tom Yan 2021-06-28 17:52 ` Tom Yan
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.