[linux-lvm] When and why vgs command can change metadata and incur old metadata to be backed up?

[Eric Ren]

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?

Thanks in advance!
Eric

[David Teigland]

Post by Eric Ren
Hi all,
Sometimes, I see the following message in the VG metadata backups under
"""
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.

[Gionatan Danti]

Post by David Teigland

Post by Eric Ren
Hi all,
Sometimes, I see the following message in the VG metadata backups under
"""
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.

Interesting. Eric, can you show the *before* and *after* vgs textual
metadata (you should find them in /etc/lvm/archive)?

Post by David Teigland
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?

Thanks.

[David Teigland]

Post by Gionatan Danti

Post by David Teigland
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
recorded. https://bugzilla.redhat.com/show_bug.cgi?id=1455671

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

[Eric Ren]

Hi all,

Post by Gionatan Danti
Interesting. Eric, can you show the *before* and *after* vgs textual
metadata (you should find them in /etc/lvm/archive)?

Ah, I think no need to show the archives now. Alasdair and David have
given us a very good explanation, thanks for them!

Regards,
Eric

[Alasdair G Kergon]

Post by Eric Ren
"""
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

[Eric Ren]

Hi Alasdair,

Post by Alasdair G Kergon
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.)

Can you still recall the fix commit for that bug? I recently encountered
a similar
problem on 2.02.98. Thanks in advance.

Thanks,
Eric