Data recovery -- thin provisioned LVM metadata (?) problem after hardware failure

Dne 04. 05. 23 v 18:31 haaber napsal(a):
> Dear Zdenek
>
> On 5/4/23 15:17, Zdenek Kabelac wrote:
>>
>>> lvchange -ay qubes_dom0/pool00_tmeta
>>
>>
>> Looking at your 'lvs -a' output - you should be able to get this one
>> active.
>>
>>
>> You will need another LV to write fixed metadata into
>>
>> # lvcreate -L128M -n newlv? qubes_dom0
>
> He was yelling at me:
>
> # lvcreate -L128M -n newlv? qubes_dom0
>
> ? WARNING: Sum of all thin volume sizes (<1.62 TiB) exceeds the size of
> thin pools and the size of whole volume group (238.27 GiB).
> ? WARNING: You have not turned on protection against thin pools running
> out of space.
> ? WARNING: Set activation/thin_pool_autoextend_threshold below 100 to
> trigger automatic extension of thin pools before they get full.
> ? Logical volume "newlv" created.
>
> But since he seemed to live with it, I gave it a try and continued. So I
> activated tmeta by
>
> lvchange -ay qubes_dom0/pool00_tmeta
>
>>
>> Then you run
>>
>> # thin_repair -i /dev/qubes_dom0/pool00_tmeta -o /dev/qubes_dom0/newlv
>>
> # thin_repair?? -i /dev/qubes_dom0/pool00_tmeta? -o /dev/qubes_dom0/newlv
> terminate called after throwing an instance of 'std::runtime_error'
> ? what():? transaction_manager::new_block() couldn't allocate new block
> Aborted


Yeah this will need? Ming's investigation with raw binary date from your 
metadata volume

(see my 2nd. mail)

Regards


Zdenek