[linux-lvm] LVM2 Metadata structure, extents ordering, metadata corruptions
zdenek.kabelac at gmail.com
Thu Sep 29 11:41:41 UTC 2022
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
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
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'
More information about the linux-lvm