Re: Reg thin pool activation failure - transaction id mismatch

Dne 18. 09. 24 v 12:54 Lakshmi Narasimhan Sundararajan napsal(a):
> Hi Team,
> Good day all!
>
> In yet another long testing run, I see a thin pool was unable to get
> volume group thin pool activated.
> vgchange -ay <vgname> fails with
>
> ```
> /# vgchange -ay pwx3
> Thin pool pwx3-pxpool-tpool (253:25) transaction_id is 6, while expected 24.
> Thin pool pwx3-pxpool-tpool (253:25) transaction_id is 6, while expected 24.
> Thin pool pwx3-pxpool-tpool (253:25) transaction_id is 6, while expected 24.
> Thin pool pwx3-pxpool-tpool (253:25) transaction_id is 6, while expected 24.
> 3 logical volume(s) in volume group "pwx3" now active
> ```
> It had other non thin lvols in the vg that got activated successfully.
>
> I tried fixing the pool, by trying the following ``` lvconvert
> --repair pwx3 ``` but this fails to fix the thin pool.
>
> There was last configuration in the lvm config backup location.
> I fixed the transaction id and used `vgcfgrestore --force -f <patched
> config> pwx3` and this fixed the transaction id issue and vg was now
> successfully activated.


Hi


Well this sounds like you were doing something 'very unhealthy' to your 
thin-pool - possibly 'restoring' old thin-pool metadata ??

TransactionId - is basically increased with lvm2 every transaction - i.e. 
adding/removing a 'thin LV' to the thin-pool.

Difference by such a large amount means something went seriously wrong in your 
system - is thin-pool suddenly started to expose very old 'transaction_id' - 
like it it would have lost everything else  from that time - so likely also 
all the mappings of thin volumes....

So basically until we know what you were doing with your system - it's very 
hard to tell want went wrong in your particular case.

What we can say for sure is - that if you have use 'vgcfgrestore'  to fix your 
'mismatching' transaction id - you just left your thin-pool problem 'hidden'  
and it will 'bite' in the moment you will try to access your now 'lost' data.

>
> And my follow up questions are:
> 1/ what exactly is a transaction id mismatch problem?
> A little more detail about this problem will help me understand this better.
>
> 2/ Are there any known workflows that are known to create this issue?
> So I can be careful to avoid such workflows.

There can be possible a mismatch by 1 -  although we try hard to catch all 
such cases - so it should be very hard to get into such state.

Your difference  by   >1  number sounds like you were doing something very 
'unusual' to your storage that thin-pool -  you will need to expose way more 
details here...


> 3/ does recovery as above guarantee data in the pool? or is the pool
> data suspect?


Absolutely NOT.

Thin-pool metadata must be recovered properly to match  lvm2 view -  and if 
that's not possible - there is relatively lot of work to get things in correct 
shape - it can be so complex it can be simply easier to just recover from 
backup in such case.


Regards

Zdenek