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?
And when you say vi editor, do you kindly mean direct edit of HEX values on the raw metadata? 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 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 So if these got messed/corrupted... 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) Thank you R. Il giorno 29 set 2022, 12:52, alle ore 12:52, Zdenek Kabelac <zdenek.kabe...@gmail.com> ha scritto: >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@redhat.com https://listman.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
