Re: Data recovery -- thin provisioned LVM metadata (?) problem after hardware failure
Zdenek Kabelac <[email protected]>
| Newsgroups | gmane.linux.lvm.devel |
|---|---|
| Message-ID | <[email protected]> |
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 -- lvm-devel mailing list [email protected] https://listman.redhat.com/mailman/listinfo/lvm-devel