Re: LVM2 Metadata structure, extents ordering, metadata corruptions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/




[Index of Archives]     [Gluster Users]     [Kernel Development]     [Linux Clusters]     [Device Mapper]     [Security]     [Bugtraq]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]

  Powered by Linux