[linux-lvm] [PATCH 1/1] pvscan: wait for udevd

[Zdenek Kabelac]

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