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

[Zdenek Kabelac]

On 24.5.2016 15:45, Gionatan Danti wrote:
> Il 18-05-2016 15:47 Gionatan Danti ha scritto:
>>
>> One question: I did some test (on another machine), deliberately
>> killing/stopping the lvmetad service/socket. When the pool was almost
>> full, the following entry was logged in /var/log/messages
>>
>> WARNING: Failed to connect to lvmetad. Falling back to internal scanning.
>>
>> So it appears than when lvmetad is gracefully stopped/not running,
>> dmeventd correctly resort to device scanning. On the other hand, in
>> the previous case, lvmetad was running but returned "Connection
>> refused". Should/could dmeventd resort to device scanning in this case
>> also?
>>
>> ...
>>
>> Very probable. So, after a LVM update, is best practice to restart the
>> machine or at least the dmeventd/lvmetad services?
>>
>> One more, somewhat related thing: when thin pool goes full, is a good
>> thing to remount an ext3/4 in readonly mode (error=remount-ro). But
>> what to do with XFS which, AFAIK, does not support a similar
>> readonly-on-error policy?
>>
>> It is my understanding that upstream XFS has some improvements to
>> auto-shutdown in case of write errors. Did these improvements already
>> tickle to production kernels (eg: RHEL6 and 7)?
>>
>> Thanks.
>
> Sorry for the bump, I would really like to know your opinions on the above


Dmeventd should not talk to lvmetad at all - I'm saying this for years....

There are some very very hard to fix (IMHO) design issues - and locking 
lvmetad in memory would be just one of wrong (IMHO) ways forward....

Anyway - let's see how it evolves here as there are further troubles
with lvmetad & dmeventd - see i.e. here:

https://bugzilla.redhat.com/show_bug.cgi?id=1339210

Regards

Zdenek