linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
* [linux-lvm] Failed to update old PV extension headers in VG
@ 2020-07-17  7:04 Henk Kraal
  2020-07-17 16:20 ` David Teigland
  0 siblings, 1 reply; 3+ messages in thread
From: Henk Kraal @ 2020-07-17  7:04 UTC (permalink / raw)
  To: linux-lvm

Hi all,

I’ve run into an issue when trying to activate an LV which resides on a read-only loop device. When I run lvchange -a y <LV Path> I get the following error:

  Error writing device /dev/loop0p5 at 4096 length 512.
  bcache_invalidate: block (4, 0) still dirty
  Failed to write mda header to /dev/loop0p5 fd -1
  Failed to update old PV extension headers in VG recursor02-01-vg.
  Volume group "recursor02-01-vg" not found
  Cannot process volume group recursor02-01-vg

I’ve observed this issue when using LVM version 2.03.02 (Debian 10) to activate the LV. The volume I’m trying to mount comes from a host which has LVM version 2.02.168 which explains why headers are attempted to be updated.


The lvchange commando is part of a file restore procedure. The backup solution we are using (Xen Orchestra) creates chained .vhd files but is unable to access LVM volumes which reside across multiple PV’s. As restoring a full VM is often not required a solution was found in using vhdimount and losetup to access the data and get the required files from the backups.

# vhdimount 20200714T234001Z.vhd /mnt/20200714T234001Z
# losetup -P -r -f /mnt/20200714T234001Z/vhdi1
# lsblk /dev/loop0
NAME      MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
loop0       7:0    0   42G  1 loop
|-loop0p1 259:0    0  243M  1 part
|-loop0p2 259:1    0    1K  1 part
`-loop0p5 259:2    0 41.8G  1 part


Given the error I would guess the source of this issue might be caused by the following commit: https://sourceware.org/git/?p=lvm2.git;a=commit;h=070c0d31ab3847240081e7593f959b03e716923d


Is there a way I can prevent the update of the extension headers when activating the LV?

With kind regards,

Henk

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [linux-lvm] Failed to update old PV extension headers in VG
  2020-07-17  7:04 [linux-lvm] Failed to update old PV extension headers in VG Henk Kraal
@ 2020-07-17 16:20 ` David Teigland
  2020-07-18 14:28   ` Henk Kraal
  0 siblings, 1 reply; 3+ messages in thread
From: David Teigland @ 2020-07-17 16:20 UTC (permalink / raw)
  To: Henk Kraal; +Cc: linux-lvm

On Fri, Jul 17, 2020 at 09:04:32AM +0200, Henk Kraal wrote:
> Hi all,
> 

> I’ve run into an issue when trying to activate an LV which resides on a
> read-only loop device. When I run lvchange -a y <LV Path> I get the
> following error:
> 
>   Error writing device /dev/loop0p5 at 4096 length 512.
>   bcache_invalidate: block (4, 0) still dirty
>   Failed to write mda header to /dev/loop0p5 fd -1
>   Failed to update old PV extension headers in VG recursor02-01-vg.
>   Volume group "recursor02-01-vg" not found
>   Cannot process volume group recursor02-01-vg
> 
> I’ve observed this issue when using LVM version 2.03.02

> Is there a way I can prevent the update of the extension headers when
> activating the LV?

I don't think there's a way to tell that version to skip the header
update.  A more recent verson of lvm should work, and let you use the PV
without updating the header.  It will not attempt updates from commands
which are not otherwise updating lvm metadata.
Dave

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [linux-lvm] Failed to update old PV extension headers in VG
  2020-07-17 16:20 ` David Teigland
@ 2020-07-18 14:28   ` Henk Kraal
  0 siblings, 0 replies; 3+ messages in thread
From: Henk Kraal @ 2020-07-18 14:28 UTC (permalink / raw)
  To: LVM general discussion and development

[-- Attachment #1: Type: text/plain, Size: 1791 bytes --]



> On 17 Jul 2020, at 18:20, David Teigland <teigland@redhat.com> wrote:
> 
> On Fri, Jul 17, 2020 at 09:04:32AM +0200, Henk Kraal wrote:
>> Hi all,
>> 
> 
>> I’ve run into an issue when trying to activate an LV which resides on a
>> read-only loop device. When I run lvchange -a y <LV Path> I get the
>> following error:
>> 
>>  Error writing device /dev/loop0p5 at 4096 length 512.
>>  bcache_invalidate: block (4, 0) still dirty
>>  Failed to write mda header to /dev/loop0p5 fd -1
>>  Failed to update old PV extension headers in VG recursor02-01-vg.
>>  Volume group "recursor02-01-vg" not found
>>  Cannot process volume group recursor02-01-vg
>> 
>> I’ve observed this issue when using LVM version 2.03.02
> 
>> Is there a way I can prevent the update of the extension headers when
>> activating the LV?
> 
> I don't think there's a way to tell that version to skip the header
> update.  A more recent verson of lvm should work, and let you use the PV
> without updating the header.  It will not attempt updates from commands
> which are not otherwise updating lvm metadata.
> Dave

Hi Dave,

Thank you for confirming that skipping the header update probably isn’t possible as I expected. I just wanted to make sure I wasn’t going down a rabbit hole needlessly.

The older LVM headers which I’m dealing with are part of the OS of hundreds of virtual servers which I don’t control. My task is to make the data on the read-only PV accesable for retrieval. A parameter to skip the update would’t have been the best option but I guess I need figure out if I can place a (temporary) writeable layer on top of the device to work around this.

Off course I’m open to idea’s if they come to the table ;)

With kind regards,

Henk


[-- Attachment #2: Type: text/html, Size: 9054 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2020-07-18 14:28 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-17  7:04 [linux-lvm] Failed to update old PV extension headers in VG Henk Kraal
2020-07-17 16:20 ` David Teigland
2020-07-18 14:28   ` Henk Kraal

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