[linux-lvm] thin: pool target too small

Zdenek Kabelac zkabelac at redhat.com
Tue Sep 22 22:02:03 UTC 2020


Dne 21. 09. 20 v 15:47 Duncan Townsend napsal(a):
> On Mon, Sep 21, 2020 at 5:23 AM Zdenek Kabelac <zkabelac at redhat.com> wrote:
>>
>> Dne 21. 09. 20 v 1:48 Duncan Townsend napsal(a):
>>> Hello!
> 
> Ahh, thank you for the reminder. My apologies for not including this
> in my original message. I use Void Linux on aarch64-musl:
> 
>>> I had a problem with a runit script that caused my dmeventd to be
>>> killed and restarted every 5 seconds. The script has been fixed, but
>>
>> Kill dmeventd is always BAD plan.
>> Either you do not want monitoring (set to 0 in lvm.conf) - or
>> leave it to it jobs - kill dmeventd in the middle of its work
>> isn't going to end well...)
> 
> Thank you for reinforcing this. My runit script was fighting with
> dracut in my initramfs. My runit script saw that there was a dmeventd
> not under its control, and so tried to kill the one started by dracut.
> I've gone and disabled the runit script and replaced it with a stub
> that simply tried to kill the dracut-started dmeventd when it receives
> a signal.

Ok - so from looking at the resulting 'mixture' of metadata you
have in your archive and what physically present on PV header are
and now noticing this is some 'not-so-standard' distro - I'm starting to 
suspect the reason of all these troubles.

Withing 'dracut' you shouldn't be firering dmeventd at all - monitoring
should be enabled  (by vgchange --monitor y) once you switch to your rootfs
so dmenventd is execute from your rootfs!

By letting 'dmeventd' running in your 'dracut world' - it lives in its
own environment and likely its very own locking dir.

That makes it very easy your dmeventd runs in parallel with your other lvm2 
commands - and since this way it's completely unprotected
(as file-locking is what it is) - as the resize is  operation for several
seconds it has happened your 'admins' command replaced whatever dmeventd was
doing.

So I think to prevent repeated occurrence of this problem - you'll need
to ensure your system-booting will follow the pattern from distros
like Fedora.

Regards

Zdenek




More information about the linux-lvm mailing list