Dne 23. 10. 19 v 0:53 Stuart D. Gathman napsal(a):
On Tue, 22 Oct 2019, Gionatan Danti wrote:
The main thing that somewhat scares me is that (if things had not changed)
thinvol uses a single root btree node: losing it means losing *all* thin
volumes of a specific thin pool. Coupled with the fact that metadata dump
are not as handy as with the old LVM code (no vgcfgrestore), it worries me.
If you can find all the leaf nodes belonging to the root (in my btree
database they are marked with the root id and can be found by sequential
scan of the volume), then reconstructing the btree data is
straightforward - even in place.
I remember realizing this was the only way to recover a major customer's
data - and had the utility written, tested, and applied in a 36 hour
programming marathon (which I hope to never repeat). If this hasn't
occured to thin pool programmers, I am happy to flesh out the procedure.
Having such a utility available as a last resort would ratchet up the
reliability of thin pools.
There have been made great enhancements in thin_repair tool (>=0.8.5)
But of course further fixes and extensions are always welcomed by Joe.
There are unfortunately some 'limitations' what can be fixed with current
metadata format but lots of troubles we have witnessed in past are now
mostly 'covered' by the recent kernel driver. But if there is known case
causing troubles - please open BZ so we can look over it.
Regards
Zdenek
_______________________________________________
linux-lvm mailing list
linux-lvm@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
