linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Gionatan Danti <g.danti@assyoma.it>
To: Zdenek Kabelac <zkabelac@redhat.com>,
	LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] Unexptected filesytem unmount with thin provision and autoextend disabled - lvmetad crashed?
Date: Tue, 17 May 2016 15:09:38 +0200	[thread overview]
Message-ID: <573B1812.3080802@assyoma.it> (raw)
In-Reply-To: <5739B848.3060505@redhat.com>



> 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?

>
> If you strictly don't care about any tracing of thin-pool fullness,
> disable  monitoring in lvm.conf.
>

While this thin pool should never be overfilled (it has a single, 
slightly smaller volume with no snapshot in place) I would really like 
to leave monitoring enabled, as it can prevent some nasty suprises (eg: 
avoid pool overfilling by a snapshot that is "forgotten" and never removed).

>
>
> 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?

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

  parent reply	other threads:[~2016-05-17 13:09 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 [this message]
2016-05-17 13:48     ` Zdenek Kabelac
2016-05-18 13:47       ` Gionatan Danti
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=573B1812.3080802@assyoma.it \
    --to=g.danti@assyoma.it \
    --cc=linux-lvm@redhat.com \
    --cc=zkabelac@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).