Re: [linux-lvm] Unexptected filesytem unmount with thin provision and autoextend disabled - lvmetad crashed?

[Zdenek Kabelac <zkabelac@redhat.com>]

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