linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Zdenek Kabelac <zkabelac@redhat.com>
To: LVM general discussion and development <linux-lvm@redhat.com>,
	Gionatan Danti <g.danti@assyoma.it>
Cc: nsoffer@redhat.com, Vojtech Juranek <vjuranek@redhat.com>
Subject: Re: [linux-lvm] Removing VG mappings using dmsetup tool
Date: Tue, 23 Jun 2020 23:53:13 +0200	[thread overview]
Message-ID: <9f9cc0bb-46b3-8b41-8532-48687af7d47d@redhat.com> (raw)
In-Reply-To: <d3cc86165ae3e27950b359dbf4eae1fe@assyoma.it>

Dne 23. 06. 20 v 23:34 Gionatan Danti napsal(a):
> Il 2020-06-23 23:02 Zdenek Kabelac ha scritto:
>> Hi
>>
>> ATM skilled admin can always easily enforce:
>>
>> 'dmsetup remove --force�� vg-lv'
> 
> Hi Zdenek,
> sure, but I find messing with dmsetup more error prone than using an LVM command.
> 
>> for i.e. linear devices to achieve this goal - however resolving this
>> at lvm2 is actually way more complex task when you start to consider
>> the situation
>> should be at least 'somehow' recoverable - it's quite complicated and
>> not really highly demanded functionality.
>> It's more simple if you have constrained world of known types of devices
>> and known use-case you are targeting to solve.
> 
> Would be an initial minimal support userful? For example, something as 
> "lvchange --error vg/lvm" which will only work on simple setup, while on more 
> complex ones would simply print a warning and return with exit code 1.
> 

There are 'couple' issue -

a) it would be nice to have this 'change' permanent ->  metadata update ->
but likely this user runs when some devices got missing - so lots of related 
trouble with 'MISSING' devices and metadata update.

b) when this would be only '--replacewitherror  y|n'  lvchange modifier - then
with next i.e. lvchange --refresh (or any other 'transient' table update) you 
get very same problematic reference of original PV.

c) it's unclear if we want to actually provide this as 'lvremove' feature - as
IMHO when 'error' replacement is required  - the most cleanest proceed is to 
never use this device again -  and ATM you can't  remove  'device' in use -
but with this kind of support we could probably migrate such device into
just 'error' placeholders (removable once devices are unused)  and space would
be relased in VG  (this would be probably my favorite path to add support
for this kind of forcible removal of used LV).

Regards

Zdenek

  reply	other threads:[~2020-06-23 21:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-23 14:26 [linux-lvm] Removing VG mappings using dmsetup tool Vojtech Juranek
2020-06-23 20:28 ` Zdenek Kabelac
2020-06-23 20:37   ` Gionatan Danti
2020-06-23 21:02     ` Zdenek Kabelac
2020-06-23 21:34       ` Gionatan Danti
2020-06-23 21:53         ` Zdenek Kabelac [this message]
2020-06-24  7:46   ` Vojtech Juranek

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=9f9cc0bb-46b3-8b41-8532-48687af7d47d@redhat.com \
    --to=zkabelac@redhat.com \
    --cc=g.danti@assyoma.it \
    --cc=linux-lvm@redhat.com \
    --cc=nsoffer@redhat.com \
    --cc=vjuranek@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).