From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx1.redhat.com (ext-mx11.extmail.prod.ext.phx2.redhat.com [10.5.110.16]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s2TGjpFI015109 for ; Sat, 29 Mar 2014 12:45:51 -0400 Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s2TGjnpe024850 for ; Sat, 29 Mar 2014 12:45:49 -0400 Received: by mail-qa0-f53.google.com with SMTP id w8so6526848qac.12 for ; Sat, 29 Mar 2014 09:45:48 -0700 (PDT) MIME-Version: 1.0 Sender: derek.dongray@gmail.com In-Reply-To: References: Date: Sat, 29 Mar 2014 16:45:48 +0000 Message-ID: From: Derek Dongray Content-Type: multipart/alternative; boundary=047d7bdc7fc6ee6e4404f5c18c4e Subject: Re: [linux-lvm] How do I remove a locked Logical Volume ([pvmove0]) left over after a disk error? Reply-To: LVM general discussion and development List-Id: LVM general discussion and development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , List-Id: To: linux-lvm@redhat.com --047d7bdc7fc6ee6e4404f5c18c4e Content-Type: text/plain; charset=ISO-8859-1 Actually the solution turned out to be simple. vgcfgbackup a [edit out the volume pvmove0] vgcfgrestore a Problem solved. . On 29 March 2014 12:02, Derek Dongray wrote: > > 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. > > > 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. > > > (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. > > > On 27 March 2014 11:32, Derek Dongray wrote: > >> 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'] >> >> -- >> Derek. >> > > > > -- > Derek. > -- Derek. --047d7bdc7fc6ee6e4404f5c18c4e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Actually the solution turned out to be simple.

vgcfgbackup a
[edit out the volume pvmove0]
vgc= fgrestore a

Problem solved.
.


On 29 March 2= 014 12:02, Derek Dongray <derek@inverchapel.me.uk> wro= te:
&=
gt; pvmove --abort has to work - unless you have some ancient version of lv=
m2 tools?

The first thing I tried, several times,=
 including with '--force', no effect. The fact that the system allo=
ws 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=
.
> 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.

> (You could always hack your lvm2 metadata in 'vi' - if you kno=
w 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 ignor= e it as it doesn't seem to cause any problem!

Derek.

On 27 March 2014 11:32, Derek Dongray <derek@inverchapel.me.uk> wrote:
Following some disk er= rors 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 i= s shown as 4Mb long.

=A0 =A0 # lvs -a -o+seg_pe_ranges a/pvmove0
=A0 = =A0 =A0 LV =A0 =A0 =A0 =A0VG =A0 Attr =A0 =A0 =A0 LSize Pool Origin Data% = =A0Move Log Cpy%Sync Convert PE Ranges
=A0 =A0 =A0 [pvmove0] a = =A0 =A0vwC---v--- 4.00m

The simple 'lvremove a/pvmove0' (optionally with '--force&= #39;) results in the message 'Can't remove locked LV pvmove0'.<= br>

'pvmove --abort' does nothing. The pre= sence of this volume doesn't seem to affect other moves (which simply u= se [pvmove1]).

In the config, the LV shows:

= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pvmove0 {
=A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 id =3D "54veYD-hM8r-j214-MOD1-FGnV-3g7t-jRlZ7= W"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 status = =3D ["READ", "WRITE", "LOCKED"]
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 flags =3D []
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 creation_host =3D "zo= tac"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 creatio= n_time =3D 1394764593 =A0 =A0 =A0# 2014-03-14 02:36:33 +0000
=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 allocation_policy =3D "con= tiguous"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 segment_count =3D 1

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 segm= ent1 {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 start_extent =3D 0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 extent_count =3D 1 =A0 =A0 =A0 =A0# 4 Megabytes=

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 type =3D "error"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 }
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }

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 con= fig file to remove the offending LV and then use `vgcfgrestore` (or possibl= e 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 s= imultaneous failure of 2 out of 3 disks in a RAID array; fortunately one th= e drives only had a few bad blocks so I was able to recover all but a few m= egabytes of a 500Gb volume using 'ddrescue']

--
Derek.



--
Derek.



--
Derek. --047d7bdc7fc6ee6e4404f5c18c4e--