[linux-lvm] LVM2 Metadata structure, extents ordering, metadata corruptions
Roberto Fastec
roberto.fastec at gmail.com
Thu Sep 29 12:12:06 UTC 2022
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.kabelac at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-lvm/attachments/20220929/3cdf2035/attachment-0001.htm>
More information about the linux-lvm
mailing list