linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Gionatan Danti <assistenza@assyoma.it>
To: LVM general discussion and development <linux-lvm@redhat.com>
Cc: 'Gionatan Danti' <assistenza@assyoma.it>
Subject: Re: [linux-lvm] Unexptected filesytem unmount with thin provision and autoextend disabled - lvmetad crashed?
Date: Wed, 18 May 2016 15:47:23 +0200	[thread overview]
Message-ID: <573C726B.6020209@assyoma.it> (raw)
In-Reply-To: <573B213E.7060807@redhat.com>

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:
>
> https://bugzilla.redhat.com/1334063
>
> possibly? targeted by this commit:
>
> https://git.fedorahosted.org/cgit/lvm2.git/commit/?id=7ef152c07290c79f47a64b0fc81975ae52554919
>

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.


-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@assyoma.it - info@assyoma.it
GPG public key ID: FF5F32A8

  reply	other threads:[~2016-05-18 13:52 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-15 10:33 [linux-lvm] Unexptected filesytem unmount with thin provision and autoextend disabled - lvmetad crashed? Gionatan Danti
2016-05-16 12:08 ` Zdenek Kabelac
2016-05-16 13:01   ` Xen
2016-05-16 14:09     ` Zdenek Kabelac
2016-05-16 19:25       ` Xen
2016-05-16 21:39         ` Xen
2016-05-17  9:43         ` Zdenek Kabelac
2016-05-17 17:17           ` Xen
2016-05-17 19:18             ` Zdenek Kabelac
2016-05-17 20:43               ` Xen
2016-05-17 22:26                 ` Zdenek Kabelac
2016-05-18  1:34                   ` Xen
2016-05-18 12:15                     ` Zdenek Kabelac
2016-05-17 13:09   ` Gionatan Danti
2016-05-17 13:48     ` Zdenek Kabelac
2016-05-18 13:47       ` Gionatan Danti [this message]
2016-05-24 13:45         ` Gionatan Danti
2016-05-24 14:17           ` Zdenek Kabelac
2016-05-24 14:28             ` Gionatan Danti
2016-05-24 17:17               ` Zdenek Kabelac
     [not found] <766997897.3926921.1463545271031.JavaMail.yahoo.ref@mail.yahoo.com>
2016-05-18  4:21 ` matthew patton
     [not found] <1872684910.4114972.1463547443287.JavaMail.yahoo.ref@mail.yahoo.com>
2016-05-18  4:57 ` matthew patton
2016-05-18 14:20   ` Xen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=573C726B.6020209@assyoma.it \
    --to=assistenza@assyoma.it \
    --cc=linux-lvm@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).