On 22.5.2016 19:07, Xen wrote:
I am not sure if, due to my recent posts ;-) I would still be allowed to write
here. But, perhaps it is important regardless.
I have an embedded LVM. The outer volume is a cached LVM, that is to say, two
volumes are cached from a different PV. One of the cached volumes contains LUKS.
The LUKS, when opened, contains another PV, VG, and a thin pool.
The thin pool contains about 4-5 partitions and is overprovisioned. Only one
volume is in use now.
This thin volume called "Store" is almost the full size of the thin pool, but
not quite:
store vault Vwi-aotz-- 400.00g thin 40.37
It currently stores a backup, I was writing some backup scripts.
The volume apparently got umounted when the meta of the thinpool reached 80%.
10:47:21 lvm[4657]: WARNING: Thin pool vault-thin-tpool metadata is now 80.14%
full.
10:47:21 lvm[4657]: Request to lookup VG vault in lvmetad gave response
Connection reset by peer.
10:47:21 lvm[4657]: Volume group "vault" not found
10:47:21 lvm[4657]: Failed to extend thin pool vault-thin-tpool.
At this moment - any failure in 'lvresize' execution leads to immediate
umount - tool went ballistic and so takes 'drastic' action to prevent further
damage.
See here again:
https://www.redhat.com/archives/linux-lvm/2016-May/msg00064.html
ATM there is some new code which unconditionally always connects to lvmetad
even it's not necessary at all - and it's potential source of many other
troubles - so fixes here are in progress - set 'use_lvmetad=0' if it's
still a problem in your case.
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/
