Dne 19. 02. 21 v 17:37 David Teigland napsal(a):
On Thu, Feb 18, 2021 at 04:19:01PM +0100, Martin Wilck wrote:
Feb 10 17:24:26 archlinux lvm[643]: pvscan[643] VG sys run
autoactivation.
Feb 10 17:24:26 archlinux lvm[643]: /usr/bin/dmeventd: stat failed:
No such file or directory
What's going on here? pvscan trying to start dmeventd ? Why ? There's a
dedicated service for starting dmeventd (lvm2-monitor.service). I can
see that running dmeventd makes sense as you have thin pools, but I'm
at a loss why it has to be started at that early stage during boot
already.
This is a curious message, it looks as if pvscan was running from an
environment (initramfs??) where dmeventd wasn't available. The message
is repeated, and after that, pvscan appears to hang...
I've found that when pvscan activates a VG, there's a bit of code that
attempts to monitor any LVs that are already active in the VG. Monitoring
means interacting with dmeventd. I don't know why it's doing that, it
seems strange, but the logic around monitoring in lvm seems ad hoc and in
need of serious reworking. In this case I'm guessing there's already an
LV active in "sys", perhaps from direct activation in initrd, and when
pvscan activates that VG it attempts to monitor the already active LV.
The existing design for lvm2 rootfs using was like:
Activate 'LV' within ramdisk by dracut - which discovers rootfs VG/LV
and activates it (by rather 'brute-force' naive approach).
Such activation is WITHOUT monitoring - as ramdisk is without 'dmeventd'
and we do not want to 'lock' the binary from ramdisk into memory.
So once the system switches to rootfs - 'vgchange --monitor y' enables
monitoring for all activated LVs from ramdisk and process continues.
Event based activation within ramdisk is a 3rd. party initiative by Arch linux
and thus needs to be 'reinvented' with its own problems that arise from this.
So far - in lvm2 the current dracut method is more maintainable.
Another missing piece in lvm monitoring is that we don't have a way to
start lvm2-monitor/dmeventd at the right time (I'm not sure anyone even
knows when the right time is), so we get random behavior depending on if
it's running or not at a given point. In this case, it looks like it
happens to not be running yet. I sometimes suggest disabling lvm2-monitor
and starting it manually once the system is up, to avoid having it
interfere during startup.
Right time is when switch is finished and we have rootfs with /usr
available - should be ensured by lvm2-monitor.service and it dependencies.
Zdenek
_______________________________________________
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/
