[linux-lvm] How do I remove a locked Logical Volume ([pvmove0]) left over after a disk error?

[Derek Dongray]

Following some disk errors while I was moving some extents, I now have a
hidden locked [pvmove0] which doesn't seem to have any physical extents
assigned, although it is shown as 4Mb long.

# lvs -a -o+seg_pe_ranges a/pvmove0
LV VG Attr LSize Pool Origin Data% Move Log Cpy%Sync
Convert PE Ranges
[pvmove0] a vwC---v--- 4.00m

The simple 'lvremove a/pvmove0' (optionally with '--force') results in the
message 'Can't remove locked LV pvmove0'.

'pvmove --abort' does nothing. The presence of this volume doesn't seem to
affect other moves (which simply use [pvmove1]).

In the config, the LV shows:

pvmove0 {
id = "54veYD-hM8r-j214-MOD1-FGnV-3g7t-jRlZ7W"
status = ["READ", "WRITE", "LOCKED"]
flags = []
creation_host = "zotac"
creation_time = 1394764593 # 2014-03-14
02:36:33 +0000
allocation_policy = "contiguous"
segment_count = 1

segment1 {
start_extent = 0
extent_count = 1 # 4 Megabytes

type = "error"
}
}

I noticed there's no physical volume associate with the LV although the
extent count of 1 explains why it's reported as 4Mb in size.

I suspect that the only fix is to manually edit the config file to remove
the offending LV and then use `vgcfgrestore` (or possible simply edit the
config file from a rescue system) but would assume that I'm not the only
person to have this problem and would think there's a series of (possibly
undocumented) commands to clean this up.

[FYI: the 'disk errors' were the almost simultaneous failure of 2 out of 3
disks in a RAID array; fortunately one the drives only had a few bad blocks
so I was able to recover all but a few megabytes of a 500Gb volume using
'ddrescue']

[Zdenek Kabelac]

This post might be inappropriate. Click to display it.

[Derek Dongray]

Post by Zdenek Kabelac
pvmove --abort has to work - unless you have some ancient version of lvm2 tools?

The first thing I tried, several times, including with '--force', no
effect. The fact that the system allows move on the same LV I was
trying to move when it failed would inidicate that it's not in a state
where a pvmove is considered to be in progress.

Post by Zdenek Kabelac
What's the vresion in use ?

# lvm version
LVM version: 2.02.104(2) (2013-11-13)
Library version: 1.02.83 (2013-11-13)
Driver version: 4.26.0


It the current Debian testing version. Kernel 3.12-1-686-pae.

Post by Zdenek Kabelac
(You could always hack your lvm2 metadata in 'vi' - if you know what you
are doing...)

I'm beginning to think that's the only way to get rid of it. Of course, the
other solution is to simply ignore it as it doesn't seem to cause any
problem!

Derek.

Post by Zdenek Kabelac
Following some disk errors while I was moving some extents, I now have a
hidden locked [pvmove0] which doesn't seem to have any physical extents
assigned, although it is shown as 4Mb long.
# lvs -a -o+seg_pe_ranges a/pvmove0
LV VG Attr LSize Pool Origin Data% Move Log Cpy%Sync
Convert PE Ranges
[pvmove0] a vwC---v--- 4.00m
The simple 'lvremove a/pvmove0' (optionally with '--force') results in the
message 'Can't remove locked LV pvmove0'.
'pvmove --abort' does nothing. The presence of this volume doesn't seem to
affect other moves (which simply use [pvmove1]).
pvmove0 {
id = "54veYD-hM8r-j214-MOD1-FGnV-3g7t-jRlZ7W"
status = ["READ", "WRITE", "LOCKED"]
flags = []
creation_host = "zotac"
creation_time = 1394764593 # 2014-03-14
02:36:33 +0000
allocation_policy = "contiguous"
segment_count = 1
segment1 {
start_extent = 0
extent_count = 1 # 4 Megabytes
type = "error"
}
}
I noticed there's no physical volume associate with the LV although the
extent count of 1 explains why it's reported as 4Mb in size.
I suspect that the only fix is to manually edit the config file to remove
the offending LV and then use `vgcfgrestore` (or possible simply edit the
config file from a rescue system) but would assume that I'm not the only
person to have this problem and would think there's a series of (possibly
undocumented) commands to clean this up.
[FYI: the 'disk errors' were the almost simultaneous failure of 2 out of 3
disks in a RAID array; fortunately one the drives only had a few bad blocks
so I was able to recover all but a few megabytes of a 500Gb volume using
'ddrescue']
--
Derek.

[Derek Dongray]

Actually the solution turned out to be simple.

vgcfgbackup a
[edit out the volume pvmove0]
vgcfgrestore a

Problem solved.
.

Post by Zdenek Kabelac
pvmove --abort has to work - unless you have some ancient version of lvm2 tools?

The first thing I tried, several times, including with '--force', no effect. The fact that the system allows move on the same LV I was trying to move when it failed would inidicate that it's not in a state where a pvmove is considered to be in progress.

Post by Zdenek Kabelac
What's the vresion in use ?

# lvm version
LVM version: 2.02.104(2) (2013-11-13)
Library version: 1.02.83 (2013-11-13)
Driver version: 4.26.0
It the current Debian testing version. Kernel 3.12-1-686-pae.

Post by Zdenek Kabelac
(You could always hack your lvm2 metadata in 'vi' - if you know what you
are doing...)

I'm beginning to think that's the only way to get rid of it. Of course,
the other solution is to simply ignore it as it doesn't seem to cause any
problem!
Derek.

Post by Zdenek Kabelac
Following some disk errors while I was moving some extents, I now have a
hidden locked [pvmove0] which doesn't seem to have any physical extents
assigned, although it is shown as 4Mb long.
# lvs -a -o+seg_pe_ranges a/pvmove0
LV VG Attr LSize Pool Origin Data% Move Log
Cpy%Sync Convert PE Ranges
[pvmove0] a vwC---v--- 4.00m
The simple 'lvremove a/pvmove0' (optionally with '--force') results in
the message 'Can't remove locked LV pvmove0'.
'pvmove --abort' does nothing. The presence of this volume doesn't seem
to affect other moves (which simply use [pvmove1]).
pvmove0 {
id = "54veYD-hM8r-j214-MOD1-FGnV-3g7t-jRlZ7W"
status = ["READ", "WRITE", "LOCKED"]
flags = []
creation_host = "zotac"
creation_time = 1394764593 # 2014-03-14
02:36:33 +0000
allocation_policy = "contiguous"
segment_count = 1
segment1 {
start_extent = 0
extent_count = 1 # 4 Megabytes
type = "error"
}
}
I noticed there's no physical volume associate with the LV although the
extent count of 1 explains why it's reported as 4Mb in size.
I suspect that the only fix is to manually edit the config file to remove
the offending LV and then use `vgcfgrestore` (or possible simply edit the
config file from a rescue system) but would assume that I'm not the only
person to have this problem and would think there's a series of (possibly
undocumented) commands to clean this up.
[FYI: the 'disk errors' were the almost simultaneous failure of 2 out of
3 disks in a RAID array; fortunately one the drives only had a few bad
blocks so I was able to recover all but a few megabytes of a 500Gb volume
using 'ddrescue']
--
Derek.

--
Derek.