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

From: Zdenek Kabelac <zkabelac@redhat.com>
To: LVM general discussion and development <linux-lvm@redhat.com>,
	David Teigland <teigland@redhat.com>,
	Martin Wilck <mwilck@suse.com>
Cc: Oleksandr Natalenko <oleksandr@redhat.com>,
	linux-lvm@e1890.dsca.akamaiedge.net,
	Christian Hesse <list@eworm.de>,
	Heming Zhao <heming.zhao@suse.com>
Subject: Re: [linux-lvm] [PATCH 1/1] pvscan: wait for udevd
Date: Fri, 19 Feb 2021 23:47:53 +0100	[thread overview]
Message-ID: <22b3cc5b-24fb-a684-be90-1f767d5ac678@redhat.com> (raw)
In-Reply-To: <20210219163722.GA13644@redhat.com>

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@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/