On Tue, Sep 29, 2020, 10:54 AM Zdenek Kabelac <zkabelac@xxxxxxxxxx> wrote:
Dne 29. 09. 20 v 16:33 Duncan Townsend napsal(a):
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.
That's good news! However, I believe I lack the requisite experience. Is
there some documentation that I ought to read as a starting point? Or is it
best to just read the source?
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)
After reading more about lvm locking, it looks like the original issue
might have been that the locking directory lives on a lv instead of on a
non-lvm-managed block device. (Although, the locking directory is on a
different vg on a different pv from the one that had the error.)
Is there a way to make dmeventd (or any other lvm program) abort if this
locking fails? Should I switch to using a clustered locking daemon (even
though I have only the single, non-virtualized host)?
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.
All I did was use vgcfgrestore to apply the metadata file attached to your
previous private email. I had to edit the transaction number, as I noted
previously. That was a single line change. Was that the wrong thing to do?
I lack the experience with lvm/thin metadata, so I am flying a bit blind
here. I apologize if I've made things worse.
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.
Thank you very much. I am extremely grateful that you've helped me so much
in repairing my system.
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...
Noted. I believe I'll be switching to glibc because there are a number of
other packages that are broken for this distro.
If you have an interest, this is the issue I've opened with my distro
about the crash: https://github.com/void-linux/void-packages/issues/25125
. I despair that this will receive much attention, given that not even gdb
works properly.
