archive mirror
 help / color / mirror / Atom feed
From: David Teigland <>
To: Nir Soffer <>
Cc: "Nisan, Tal" <>,
	Denis Chaplygin <>,
Subject: Re: [linux-lvm] WARNING: Combining activation change with other commands is not advised - why?
Date: Mon, 15 Oct 2018 09:22:46 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Sun, Oct 14, 2018 at 04:58:29PM +0300, Nir Soffer wrote:
> We (oVirt) combine lvm activation with adding and deleting tags.
> Here is example command we use:
> /usr/sbin/lvm lvchange --config ' devices { preferred_names =
> ["^/dev/mapper/"] ignore_suspended_devices=1 write_cache_state=0
> disable_after_error_count=3 filter = [
> '\''a|/dev/mapper/3600a098038304437415d4b6a59676c56|/dev/mapper/3600a098038304437415d4b6a59676c57|/dev/mapper/3600a098038304437415d4b6a59676c65|/dev/mapper/3600a098038304437415d4b6a59676c66|/dev/mapper/3600a098038304437415d4b6a59676c6d|/dev/mapper/3600a09803830443715d4b6a59676c76|/dev/mapper/3600a098038304437415d4b6a59676c78|/dev/mapper/3600a098038304437415d4b6a59676d43|/dev/mapper/3600a098038304437415d4b6a59676d46|/dev/mapper/3600a098038304437415d4b6a59676d47|/dev/mapper/3600a098038304437415d4b6a59676d4a|/dev/mapper/3600a098038304437415d4b6a59676d4f|/dev/mapper/3600a098038304437415d4b6a59676d50|/dev/mapper/3600a098038304437415d4b6a59676d51|/dev/mapper/3600a098038304437415d4b6a59676d52|'\'',
> '\''r|.*|'\'' ] }  global {  locking_type=1  prioritise_write_locks=1
> wait_for_locks=1  use_lvmetad=0 }  backup {  retain_min = 50  retain_days =
> 0 } ' --autobackup n -a y --deltag IU_4181c731-8b1a-4929-9c30-f3bfa011c129
> --addtag IU__remove_me_ZERO_4181c731-8b1a-4929-9c30-f3bfa011c129
> c80a5bd0-809e-4c4e-97a8-111611105b3e/885511bd-7164-458f-a1ac-1f8ad4355972
> And we get these warnings - this seems to be new  behavior in RHEL 7.5:
>   WARNING: This metadata update is NOT backed up.
>   WARNING: Combining activation change with other commands is not advised.
> Why combining activation with other commands is not advised?

Because they are very different operations.  lvchange is doing two
entirely different commands back to back.  There are various downsides and
lots of ambiguity to doing that.  "Compound commands" were never
introduced in a very planned way, but ad hoc here and there.  They are not
done consistently, the results and errors can be hard to determine,
options used by both commands may be interpreted differently in each (or
you might want to use an option in one command where it means one thing,
but not in the other command where it means something else.)  Or, what if
the first fails, should we go ahead and do the second?  Or which should
happen first anyway?  Or what if the second part depends on the first
part?  All of those things would generally be unpredictable with undefined

This appeared in Feb 2017, after we went through the long process of
identifying and programmatically defining each unique lvm command
definition (run 'lvm help all' to see the full list).  Before this nobody
knew what all the lvm commands were, and we sometimes discovered commands
existed that had never really been intended.  Unfortunately, because of
our fairly strict handling of backward compat, we had to leave a lot of
unwanted commands in place in case someone happened to be using it.

           reply	other threads:[~2018-10-15 14:22 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <>]

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:

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

  git send-email \ \ \ \ \ \ \

* 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).