[linux-lvm] thin: pool target too small

[Zdenek Kabelac]

Dne 29. 09. 20 v 16:33 Duncan Townsend napsal(a):
> On Sat, Sep 26, 2020, 8:30 AM Duncan Townsend <duncancmt at gmail.com 
> <mailto:duncancmt at gmail.com>> wrote:
> 
>>      > > There were further error messages as further snapshots were attempted,
>      > > but I was unable to capture them as my system went down. Upon reboot,
>      > > the "transaction_id" message that I referred to in my previous message
>      > > was repeated (but with increased transaction IDs).
>      >
>      > For better fix it would need to be better understood what has happened
>      > in parallel while 'lvm' inside dmeventd was resizing pool data.
> 

So the lvm2 has been fixed upstream to report more educative messages to
the user - although it still does require some experience in managing
thin-pool kernel metadata and lvm2 metadata.

>     To the best of my knowledge, no other LVM operations were in flight at
>     the time. The script that I use issues LVM commands strictly

In your case - dmeventd did 'unlocked' resize - while other command
was taking a snapshot - and it happened the sequence with 'snapshot' has
won - so until the reload of thin-pool - lvm2 has not spotted difference.
(which is simply a bad race cause due to badly working locking on your system)


>     Would it be reasonable to use vgcfgrestore again on the
>     manually-repaired metadata I used before? I'm not entirely sure what

You will need to vgcfgrestore - but I think you've misused my passed recoverd 
piece, where I've specifically asked to only replace specific segments of 
resized thin-pool within your latest VG metadata - since those likely have
all the proper mappings to thin LVs.

While you have taken the metadata from 'resize' moment - you've lost all
the thinLV lvm2 metadata for later created one.

I'll try to make one for you.

>     to look for while editing the XML from thin_dump, and I would very
>     much like to avoid causing further damage to my system. (Also, FWIW,
>     thin_dump appears to segfault when run with musl-libc instead of

Well - lvm2 is glibc oriented project - so users of those 'esoteric'
distribution need to be expert on its own.

If you can provide coredump or even better patch for crash - we might
replace the code with something better usable - but there is zero testing
with anything else then glibc...


Zdenek