linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Alasdair G Kergon <agk@redhat.com>
To: Eric Ren <zren@suse.com>
Cc: LVM general discussion and development <linux-lvm@redhat.com>
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 22:56:24 +0000	[thread overview]
Message-ID: <20171030225624.GA26719@agk-dp.fab.redhat.com> (raw)
In-Reply-To: <a118652b-470d-0524-7a6a-109fea394895@suse.com>

On Mon, Oct 30, 2017 at 02:06:45PM +0800, Eric Ren wrote:
> """
> 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?

Very simply if the metadata the command has just read in does not match
the last backup stored in the local filesystem and the process is able
and configured to write a new backup.

The command that made the metadata change might not have written a
backup if it crashed, was configured not to write backups, was running
with the filesystem readonly (e.g. booted into a recovery mode), ran on
a different node in a cluster, ran as part of an installer that chose
not to give you any metadata backups, performed metadata recovery etc.
(Plus an old release had a bug where the checking went wrong and it
made a backup every time even though nothing had actually changed.)

Alasdair

  parent reply	other threads:[~2017-10-30 22:56 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
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 [this message]
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:
  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=20171030225624.GA26719@agk-dp.fab.redhat.com \
    --to=agk@redhat.com \
    --cc=linux-lvm@redhat.com \
    --cc=zren@suse.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).