Thank you for all the details and for your kind replies I will have a look to the utilities you kindly pointed out
Kind regards Il giorno 29 set 2022, 13:41, alle ore 13:41, Zdenek Kabelac <zdenek.kabe...@gmail.com> ha scritto: >Dne 29. 09. 22 v 13:15 Roberto Fastec napsal(a): >> Hello Zdenek >> Thank you for the explanation >> >> May I kindly ask you what/which is the command line API to access and > >> manipulate those metadata? >> > >'command line API' in the mean of: > >To create LV -- 'lvcreate'.... >To remove LV -- 'lvremove'.... > > >Note - many command can actually work without physical interaction with >DM >layer (--driverloaded n) - however in some case some targets require >presence >of DM. > >lvm2 commands are the way how to change your metadata properly. > > >> And when you say vi editor, do you kindly mean direct edit of HEX >values on >> the raw metadata? > >No way - you can't change metadata on disk - unless you would be >basically >precisely copying what lvm2 command does - so what would be the point >?? > >Simply use lvm2 command to make the job. Unless I'm missing some >important >point why would you need to work with lvm2 metadata but without lvm2 >?? > > >> >> Thank you >> >> If you kindly may have some link to some documentation, thank you >even more >> >> Though here it is not the configuration that got lost > >Well yeah - it will take some time - but i.e. RHEL storage >documentation might >be a good way to go through it. > > > >> Also, additional info, we now got that all the cases do have active >the >> thin-provisionin and looks like that these are additional/different >metadata >> tables > >This-provisioning is handled by LVM2 only to provide LVs for metadata >and >data LVs - and then the thinLVs to a user. > >Physical block layout for thin-provisioning is fully stored inside >thin-pool's metadata device. > >To explore those mappings you need to use tools like 'thin_dump', >'thin_ls' > >> >> So if these got messed/corrupted... >> > >If these thin-pool metadata get corrupted, there is tool: >'thin_repair'. > >Note: corruption of some high-level bTree nodes may result a severe >damage to >whole metadata structure -> i.e. lots of thinLVs being lost. > >It's a good idea to keep such metadata on some resilient type of >storage >(raid) and of course rule #1 - create regular backups of your thin >volumes... (snapshot of thinLV is not a backup!). > > >> In QNAP looks they have made some customization and so thin-provision >LVM >> metadata are on a dedicated partition >> >> we observed the HEX inside there and got partially the logic >> >> About thin-provisioning, again, any "fsck"-like is available? (I >suppose no, >> but just as confirmation) > >This tool is called 'thin_check' > >(and this tool is in fact executed with every thin-pool activation & >deactivation by default by lvm2) > >Note: just like with lvm2 metadata - also thin-pool's kernel metadata >are >check-summed (protected agains disc bit corruptions), so again zero >chance >with any 'hex-editor' to manipulate them - unless you would 'recreate' >thin-pool engine... > > >Regards > >Zdenek
_______________________________________________ linux-lvm mailing list linux-lvm@redhat.com https://listman.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
