archive mirror
 help / color / mirror / Atom feed
From: David Teigland <>
To: Gionatan Danti <>
Cc: Eric Ren <>,
	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 13:50:00 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Mon, Oct 30, 2017 at 07:11:16PM +0100, Gionatan Danti wrote:
> > 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.
> Just to know: why the idea of syslog reporting was discarded?

It was so obviously correct to me that I had a hard time arguing for it.
I don't think any of the objections were satisfactory, e.g. nobody has
asked, nobody needs it, the metadata archives are good enough, you can
already configure log messages to go to syslog.

I am still hoping to do something like this either as a part of
centralizing metadata repair (in progress), or as a part of a broader
suggestion that did get a better response but will take more work.  That
was to create a new log file and format in which every lvm disk change is

Everyone is encouraged to give their feedback about that in that bz, or
create an "issue" on the lvm github.

  reply	other threads:[~2017-10-30 18:50 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 [this message]
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).