All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.