Dne 15.5.2018 v 10:11 Dennis Schridde napsal(a):
Hello!
In case the question comes up: Fedora 28 (the live system I am trying to use
for recovery) is using Linux 4.16.3-301.fc28 and `lvm version`:
LVM version 2.02.177(2)
Library version 1.02.146
Driver version 4.37.0
The system I was originally using to break the cache was using Linux 4.16.7-
gentoo, and `LD_LIBRARY_PATH=$PWD/lib64 ./bin/lvm version` from its initrd
reports (running on the Fedora 28 live system):
LVM version: 2.02.173(2)
Library version: 1.02.142
Driver version: 4.37.0
Could someone please give me a hint what is actually broken here? Is it just
the metadata? If so, how can that break -- shouldn't that metadata never be
modified after creating the LV? And could it not be recovered from /etc/lvm/
archive? What does "manual repair" mean in detail? Is there some way to
recover the cache? Or is it at least possible to uncache the LV forcibly, to
hopefully recover the data on the origin LV? What is your recommendation to
minimise data loss?
Hi
To get direct access to metadata - you could use your latest lvm2 2.02.177
build (or even 'git master'). In these recent versions there is added support
to activate directly these 'subLVs'. So with latest lvm2 you can:
lvchange -ay vg/lv_cmeta
and then you can capture content of this LV via 'dd' into file
and compress and attach 'xz' compressed to BZ.
(dd if=/dev/vg/lv_cmeta of=/tmp/file)
----
With older lvm2 you would need to 'swap-in' temporary LV as metadata, which
has been also documented several in the list and man pages for thin-pool.
But since you already have 2.02.177 - you should be able to activate _cmeta LV
directly.
Regards
Zdenek
_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
