<div dir="auto"><div dir="auto"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 29, 2020, 10:54 AM Zdenek Kabelac <<a href="mailto:zkabelac@redhat.com">zkabelac@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dne 29. 09. 20 v 16:33 Duncan Townsend napsal(a):<br>
> On Sat, Sep 26, 2020, 8:30 AM Duncan Townsend <<a href="mailto:duncancmt@gmail.com" target="_blank" rel="noreferrer">duncancmt@gmail.com</a> <br>
> <mailto:<a href="mailto:duncancmt@gmail.com" target="_blank" rel="noreferrer">duncancmt@gmail.com</a>>> wrote:<br>
> <br>
>>      > > There were further error messages as further snapshots were attempted,<br>
>      > > but I was unable to capture them as my system went down. Upon reboot,<br>
>      > > the "transaction_id" message that I referred to in my previous message<br>
>      > > was repeated (but with increased transaction IDs).<br>
>      ><br>
>      > For better fix it would need to be better understood what has happened<br>
>      > in parallel while 'lvm' inside dmeventd was resizing pool data.<br>
> <br>
<br>
So the lvm2 has been fixed upstream to report more educative messages to<br>
the user - although it still does require some experience in managing<br>
thin-pool kernel metadata and lvm2 metadata.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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?</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>     To the best of my knowledge, no other LVM operations were in flight at<br>
>     the time. The script that I use issues LVM commands strictly<br>
<br>
In your case - dmeventd did 'unlocked' resize - while other command<br>
was taking a snapshot - and it happened the sequence with 'snapshot' has<br>
won - so until the reload of thin-pool - lvm2 has not spotted difference.<br>
(which is simply a bad race cause due to badly working locking on your system)<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.)</div><div dir="auto"><br></div><div dir="auto">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)?</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>     Would it be reasonable to use vgcfgrestore again on the<br>
>     manually-repaired metadata I used before? I'm not entirely sure what<br>
<br>
You will need to vgcfgrestore - but I think you've misused my passed recoverd <br>
piece, where I've specifically asked to only replace specific segments of <br>
resized thin-pool within your latest VG metadata - since those likely have<br>
all the proper mappings to thin LVs.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
While you have taken the metadata from 'resize' moment - you've lost all<br>
the thinLV lvm2 metadata for later created one.<br>
<br>
I'll try to make one for you.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Thank you very much. I am extremely grateful that you've helped me so much in repairing my system.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>     to look for while editing the XML from thin_dump, and I would very<br>
>     much like to avoid causing further damage to my system. (Also, FWIW,<br>
>     thin_dump appears to segfault when run with musl-libc instead of<br>
<br>
Well - lvm2 is glibc oriented project - so users of those 'esoteric'<br>
distribution need to be expert on its own.<br>
<br>
If you can provide coredump or even better patch for crash - we might<br>
replace the code with something better usable - but there is zero testing<br>
with anything else then glibc...<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Noted. I believe I'll be switching to glibc because there are a number of other packages that are broken for this distro.</div><div dir="auto"><br></div><div dir="auto">If you have an interest, this is the issue I've opened with my distro about the crash: <a href="https://github.com/void-linux/void-packages/issues/25125">https://github.com/void-linux/void-packages/issues/25125</a> . I despair that this will receive much attention, given that not even gdb works properly.</div><div dir="auto"><br></div><div dir="auto">Thanks again!</div><div dir="auto">--Duncan Townsend</div><div dir="auto"><br></div><div dir="auto">P.S. This was written on mobile. Please forgive my typos.</div></div>