[linux-lvm] LVM2 Metadata structure, extents ordering, metadata corruptions

[Zdenek Kabelac]

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