Dne 29. 09. 20 v 16:33 Duncan Townsend napsal(a):
On Sat, Sep 26, 2020, 8:30 AM Duncan Townsend <duncancmt@xxxxxxxxx
<mailto:duncancmt@xxxxxxxxx>> 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
_______________________________________________
linux-lvm mailing list
linux-lvm@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
