[linux-lvm] LVM2 Metadata structure, extents ordering, metadata corruptions
Zdenek Kabelac
zdenek.kabelac at gmail.com
Thu Sep 29 10:52:32 UTC 2022
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
More information about the linux-lvm
mailing list