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

From: Roberto Fastec <roberto.fastec@gmail.com>
To: Zdenek Kabelac <zdenek.kabelac@gmail.com>
Cc: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] LVM2 Metadata structure, extents ordering, metadata corruptions
Date: Thu, 29 Sep 2022 14:12:06 +0200	[thread overview]
Message-ID: <06aa39c6-66bc-45be-8a69-07fd827db5bf@gmail.com> (raw)
In-Reply-To: <7f7db1ac-fe8a-851f-ef38-8aa85f9353c2@gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 3293 bytes --]

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@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

[-- Attachment #1.2: Type: text/html, Size: 4508 bytes --]

[-- Attachment #2: Type: text/plain, Size: 202 bytes --]

_______________________________________________
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/