Re: LVM2 Metadata structure, extents ordering, metadata corruptions

Dne 27. 09. 22 v 12:10 Roberto Fastec napsal(a):
> Dear friends of the LVM mailing list
> 
> I suppose this question is for some real LVM2 guru or even developer
> 
> Here I kindly make three question with three premises
> 
> premises
> 1. I'm a total noob about LVM2 low level logic, so I'm sorry of the questions 
> will sound silly :-)
> 2. The following applies to a whole md RAID (in my example it will be a RAID5 
> made of 4 drives 1TB each so useful available space more or less 2.7TB)
> 3. I assign whole those 2.7TB to one single PV and one single VG and one 
> single LV.
> 
> questions
> 1. Given the premise 3. The corresponding LVM2 metadata/tables are and will be 
> just a (allow me the term) "grid" "mapping that space" in an ordered sequence 
> to in the subsequent use (and filling) of the RAID space "just mark" the used 
> ones and the free ones? Or those grid cells will/could be in a messed order ?
> And explicitly I mean. In case of metadata corruption (always with respect of 
> premise 3.) , could we just generate a dummy metadata table with all the 
> extents marked as "used" in such a way that we can anyway access them
> And can we expect to have them ordered?

lvm2  'metadata handling'  is purely internal to the lvm2 codebase - you can't 
rely on any 'witnessed/observed' logic.

There is cmdline API to access and manipulate metadata in most cases.

Temporarily you can i.e. update/modify your current metadata with 'vi' editor 
and vgcfgrestore them - however this is not a 'guaranteed' operational mode - 
rather a workaround if the 'cmdline' interface is not handling some error case 
well - and it should be used as  RFE to enhance lvm2 in such case.

> 
> 2. Does it exist a sort of "fsck" for the LVM2 metadata ? We do technical 
> assistance and recently, specifically with those NAS devices that make use of 

In general - lvm2 metadata on disk always do have CRC32  checksum - when 
invalid -> metadata is garbage.

Each loaded CRC32 correct metadata is always then fully validated - yep it can 
be sometimes a bit costly in the case of very large metadata size - but so far 
- no big problems -  CPUs are mostly getting faster as well...  so bigger 
setups tends to have also powerful hw....

> LVM2, we have experienced really easy metadata corruption in occurence of just 
> nothing or because of a electric power interruption (which is really 
> astonishing). We mean no drives failures , no bad SMARTs . Just corruption 
> from "nowhere" and "nocause"


Corrupted metadata are always considered unusable - user has to restore to 
previous valid version (and here sometimes all the combinations of error might 
eventually require  'vi editor' assistance - but again - in very very unusual 
circumstances.

Metadata are archived in /etc/lvm/archive and  they are also in ring-buffer 
present on all PVs in a VG  -  if there are too many PVs - user can 'opt-out' 
and consider only a subset of PVs to hold metadata - i.e.  200PVs - and only 
20PVs holding metadata - but these are highly unusual configurations...

Regards


Zdenek

_______________________________________________
linux-lvm mailing list
[email protected]
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/