From mboxrd@z Thu Jan 1 00:00:00 1970 References: <4bcd585d099ecec086b99cfa5c23cc38@assyoma.it> <5739B848.3060505@redhat.com> From: Gionatan Danti Message-ID: <573B1812.3080802@assyoma.it> Date: Tue, 17 May 2016 15:09:38 +0200 MIME-Version: 1.0 In-Reply-To: <5739B848.3060505@redhat.com> Content-Transfer-Encoding: 7bit Subject: Re: [linux-lvm] Unexptected filesytem unmount with thin provision and autoextend disabled - lvmetad crashed? Reply-To: LVM general discussion and development List-Id: LVM general discussion and development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , List-Id: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Zdenek Kabelac , LVM general discussion and development > 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