From: Zdenek Kabelac <email@example.com>
To: LVM general discussion and development <firstname.lastname@example.org>,
David Teigland <email@example.com>,
Martin Wilck <firstname.lastname@example.org>
Cc: Oleksandr Natalenko <email@example.com>,
Christian Hesse <firstname.lastname@example.org>,
Heming Zhao <email@example.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: <firstname.lastname@example.org> (raw)
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: pvscan VG sys run
>>> Feb 10 17:24:26 archlinux lvm: /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
>> 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.
linux-lvm mailing list
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
next prev parent reply other threads:[~2021-02-19 22:48 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-11 11:16 [linux-lvm] [PATCH 1/1] pvscan: wait for udevd Christian Hesse
[not found] ` <email@example.com>
2021-02-17 8:22 ` Martin Wilck
[not found] ` <20210217130329.7de41147@leda>
2021-02-17 13:38 ` Oleksandr Natalenko
2021-02-18 15:19 ` Martin Wilck
2021-02-18 15:30 ` Oleksandr Natalenko
2021-02-19 9:22 ` Martin Wilck
2021-02-19 16:37 ` David Teigland
2021-02-19 22:47 ` Zdenek Kabelac [this message]
2021-02-21 20:23 ` Martin Wilck
2021-02-22 9:57 ` Zdenek Kabelac
2021-02-22 13:04 ` Christian Hesse
2021-02-25 16:51 ` Oleksandr Natalenko
2021-02-21 20:26 ` Martin Wilck
2021-02-17 13:49 ` Martin Wilck
2021-02-17 19:11 ` Oleksandr Natalenko
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).