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

Roberto Fastec roberto.fastec at gmail.com
Tue Sep 27 10:10:56 UTC 2022

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

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
3. I assign whole those 2.7TB to one single PV and one single VG and one
single LV.

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?

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

Thank you for any hint

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-lvm/attachments/20220927/275a5fbb/attachment-0001.htm>

More information about the linux-lvm mailing list