archive mirror
 help / color / mirror / Atom feed
From: David Teigland <>
To: Eric Ren <>
Cc: LVM general discussion and development <>
Subject: Re: [linux-lvm] When and why vgs command can change metadata and incur old metadata to be backed up?
Date: Mon, 30 Oct 2017 12:04:51 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Mon, Oct 30, 2017 at 02:06:45PM +0800, Eric Ren wrote:
> Hi all,
> Sometimes, I see the following message in the VG metadata backups under
> /etc/lvm/archive:
> """
> contents = "Text Format Volume Group"
> version = 1
> description = "Created *before* executing 'vgs'"
> """
> I'm wondering when and why the new backups will be created by reporting
> command like vgs?

It's probably a case where lvm sees something wrong after reading the VG
metadata, and automatically tries to fix it, writing a corrected version
of the metadata to disk.  This means that even a command that only reads
and reports lvm information can potentially write to disk.

Right now it's hard to identify the precise instances and locations of
these repairs.  But, I am in the middle of reworking the VG reading code
with the goal of consolidating and clarifying all the cases of repair, at
which point we can improve the way we handle this.  I think we want to try
to make these repairs more limited and controlled, especially for commands
that in theory are only reading and reporting information.  I've also
suggested that whenever repairs are done, lvm should record a persistent
message in the system log with the details, but that idea didn't get a
great reception.

  reply	other threads:[~2017-10-30 17:04 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-30  6:06 [linux-lvm] When and why vgs command can change metadata and incur old metadata to be backed up? Eric Ren
2017-10-30 17:04 ` David Teigland [this message]
2017-10-30 18:11   ` Gionatan Danti
2017-10-30 18:50     ` David Teigland
2017-10-31  7:54     ` Eric Ren
2017-10-30 22:56 ` Alasdair G Kergon
2017-11-04  7:24   ` Eric Ren

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