On 17.5.2016 15:09, Gionatan Danti wrote:
Well yeah - ATM we rather take 'early' action and try to stop any user
on overfill thin-pool.
It is a very reasonable standing
Basically whenever 'lvresize' failed - dmeventd plugin now tries
to unconditionally umount any associated thin-volume with
thin-pool above threshold.
For now - plugin 'calls' the tool - lvresize --use-policies.
If this tool FAILs for ANY reason -> umount will happen.
I'll probably put in 'extra' test that 'umount' happens
with >=95% values only.
dmeventd itself has no idea if there is configure 100 or less - it's
the lvresize to see it - so even if you set 100% - and you have enabled
monitoring - you will get umount (but no resize)
Ok, so the "failed to resize" error is also raised when no actual resize
happens, but the call to the "dummy" lvresize fails. Right?
Yes - in general - you've witnessed general tool failure,
and dmeventd is not 'smart' to recognize the reason of failure.
Normally this 'error' should not happen.
And while I'd even say there could have been a 'shortcut'
without even reading VG 'metadata' - since there is profile support,
it can't be known (100% threshold) without actually reading metadata
(so it's quite tricky case anyway)
Well 'lvmetad' shall not crash, ATM this may kill commands - and further
stop processing - as we rather 'stop' further usage rather than allowing
to cause bigger damage.
So if you have unusual system/device setup causing 'lvmetad' crash -
open BZ,
and meawhile set 'use_lvmetad=0' in your lvm.conf till the bug is fixed.
My 2 cents are that the last "yum upgrade", which affected the lvm tools,
needed a system reboot or at least the restart of the lvm-related services
(dmeventd and lvmetad). The strange thing is that, even if lvmetad crashed, it
should be restartable via the lvm2-lvmetad.socket systemd unit. Is this a
wrong expectation?
Assuming you've been bitten by this one:
https://bugzilla.redhat.com/1334063
possibly? targeted by this commit:
https://git.fedorahosted.org/cgit/lvm2.git/commit/?id=7ef152c07290c79f47a64b0fc81975ae52554919
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/
