* [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.