[linux-lvm] Unexptected filesytem unmount with thin provision and autoextend disabled - lvmetad crashed?
assistenza at assyoma.it
Wed May 18 13:47:23 UTC 2016
On 17/05/2016 15:48, Zdenek Kabelac wrote:
> 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)
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?
> Assuming you've been bitten by this one:
> possibly? targeted by this commit:
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
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)?
Assyoma S.r.l. - www.assyoma.it
email: g.danti at assyoma.it - info at assyoma.it
GPG public key ID: FF5F32A8
More information about the linux-lvm