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
linux-lvm@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
