[linux-lvm] pvmove failure ...

[linux-lvm] pvmove failure ...

[Timshel Knoll]

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

Hi,

I am having problems trying to pvmove stuff from one physical volume to
another. I first experienced this using kernel 2.4.3 with lvm
0.9.1beta6 and the 0.9.1beta7 Debian package of the lvm tools. I then
updated to 2.4.4 with the CVS version of lvm (as of 08/06/2001 +1000),
and I am still experiencing the same problems. Basically, pvmove simply
reports:

pvmove -- ERROR "pv_move_pe(): PE lock" pv_move_pe

pvmove -- ERROR "pv_move_pe(): PE lock" moving physical extents

and nothing is moved :-(

Attached is the gzipped output of an example session. Note that I get
this same problem if I attempt to move any of the other logical volumes
around as well :-( Any ideas/comments/tips?

Thanks,

Timshel

-- 
   Timshel Knoll <timshel@pobox.com>  for Debian email: <timshel@debian.org>
                Geomatics/Computer Science double degree, RMIT
      Debian GNU/Linux developer, see http://people.debian.org/~timshel/
                For GnuPG public key: finger timshel@debian.org

[-- Attachment #2: lvm.out.gz --]
[-- Type: application/octet-stream, Size: 7452 bytes --]

Re: [linux-lvm] pvmove failure ...

[AJ Lewis]

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

On Sat, Jun 09, 2001 at 12:40:02AM +1000, Timshel Knoll wrote:
> I am having problems trying to pvmove stuff from one physical volume to
> another. I first experienced this using kernel 2.4.3 with lvm
> 0.9.1beta6 and the 0.9.1beta7 Debian package of the lvm tools. I then
> updated to 2.4.4 with the CVS version of lvm (as of 08/06/2001 +1000),
> and I am still experiencing the same problems. Basically, pvmove simply
> reports:
> 
> pvmove -- ERROR "pv_move_pe(): PE lock" pv_move_pe
> 
> pvmove -- ERROR "pv_move_pe(): PE lock" moving physical extents
> 
> and nothing is moved :-(
> 
> Attached is the gzipped output of an example session. Note that I get
> this same problem if I attempt to move any of the other logical volumes
> around as well :-( Any ideas/comments/tips?

It appears from the attached file that you have also applied XFS patches
into the kernel.  Which version of the XFS patches did you apply?  Has
anyone else tried 'pvmove' with that combination of patches successfully?
It's possible we're seeing some kind of conflict between the two.

Also, in which order did you patch the kernel, and did you apply any other
patches?

Regards,
-- 
AJ Lewis
Sistina Software Inc.                  Voice:  612-638-0500
1313 5th St SE, Suite 111              Fax:    612-638-0500
Minneapolis, MN 55414                  E-Mail: lewis@sistina.com
http://www.sistina.com

Current GPG fingerprint = 3B5F 6011 5216 76A5 2F6B  52A0 941E 1261 0029 2648
Get my key at: http://www.sistina.com/~lewis/gpgkey
 (Unfortunately, the PKS-type keyservers do not work with multiple sub-keys)

-----Begin Obligatory Humorous Quote----------------------------------------
Chaos, panic, pandemonium - my work here is done
-----End Obligatory Humorous Quote------------------------------------------

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [linux-lvm] pvmove failure ...

[Andreas Dilger]

Timshel writes:
> I am having problems trying to pvmove stuff from one physical volume to
> another. I first experienced this using kernel 2.4.3 with lvm
> 0.9.1beta6 and the 0.9.1beta7 Debian package of the lvm tools. I then
> updated to 2.4.4 with the CVS version of lvm (as of 08/06/2001 +1000),
> and I am still experiencing the same problems. Basically, pvmove simply
> reports:
> 
> pvmove -- ERROR "pv_move_pe(): PE lock" pv_move_pe
 [Note error return is -6 => ENXIO]
> 
> pvmove -- ERROR "pv_move_pe(): PE lock" moving physical extents
> 
> and nothing is moved :-(

The ENXIO error is returned if the vg you are trying to move does not
exist (at least that's what it looks like).  This is returned from
within the kernel when vg_ptr = NULL inside lvm_do_pe_lock_unlock().

It would _appear_ that /dev/vg0/group is pointing to a bogus device.
In lvm_chr_open() you are allowed to open non-existent devices (so
that you can create new devices if desired).

When was the last time you ran vgscan and/or rebooted?  Did you do anything
strange in the meantime?

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

[linux-lvm] Re: pvmove failure ...

[Timshel Knoll]

[Sorry, should have mentioned that I'm not subscribed to get mail from
 this list - I get enough mail already ;-) - please CC all replies to me]

> It appears from the attached file that you have also applied XFS patches
> into the kernel.  Which version of the XFS patches did you apply?  Has
> anyone else tried 'pvmove' with that combination of patches successfully?
> It's possible we're seeing some kind of conflict between the two.
>
> Also, in which order did you patch the kernel, and did you apply any other
> patches?

The first version I tried was a vanilla 2.4.3 with the default LVM in it
(version 0.9.1beta6?) and the XFS 1.0 patch. The last one I tried was
the CVS version of the XFS kernel (from SGI, 2.4.4, dated 15/05/2001)
patched with the CVS version of LVM ...

I'm going to try the latest CVS XFS patched with CVS LVM, but I've got
to wait for the CVS update (which takes ages over my 56K link) :-(

Everything else is working fine, just not pvmove :-(

Thanks,

Timshel

-- 
   Timshel Knoll <timshel@pobox.com>  for Debian email: <timshel@debian.org>
                Geomatics/Computer Science double degree, RMIT
      Debian GNU/Linux developer, see http://people.debian.org/~timshel/
                For GnuPG public key: finger timshel@debian.org

[linux-lvm] Re: pvmove failure ...

[Timshel Knoll]

[please CC all replies to me, I don't read mail from this list]

> The ENXIO error is returned if the vg you are trying to move does not
> exist (at least that's what it looks like).  This is returned from
> within the kernel when vg_ptr = NULL inside lvm_do_pe_lock_unlock().
>
> It would _appear_ that /dev/vg0/group is pointing to a bogus device.
> In lvm_chr_open() you are allowed to open non-existent devices (so
> that you can create new devices if desired).
>
>When was the last time you ran vgscan and/or rebooted?  Did you do anything
>strange in the meantime?

I had just rebooted before I ran pvmove. The vg0 vg is definately a
valid vg ... I think I ran vgscan during the process of trying to get it
all to work, and nothing strange came up ...

I'll be away for the next couple of days, so I won't be recieving email
during that time ...

Thanks,

Timshel

-- 
   Timshel Knoll <timshel@pobox.com>  for Debian email: <timshel@debian.org>
                Geomatics/Computer Science double degree, RMIT
      Debian GNU/Linux developer, see http://people.debian.org/~timshel/
                For GnuPG public key: finger timshel@debian.org

[linux-lvm] Re: pvmove failure ...

[Timshel Knoll]

[please CC all replies to me, I don't read mail from this list]

On Sat, Jun 09, 2001 at 10:48:22AM +1000, Timshel Knoll wrote:
> [please CC all replies to me, I don't read mail from this list]
> 
> > The ENXIO error is returned if the vg you are trying to move does not
> > exist (at least that's what it looks like).  This is returned from
> > within the kernel when vg_ptr = NULL inside lvm_do_pe_lock_unlock().
> >
> > It would _appear_ that /dev/vg0/group is pointing to a bogus device.
> > In lvm_chr_open() you are allowed to open non-existent devices (so
> > that you can create new devices if desired).
> >
> >When was the last time you ran vgscan and/or rebooted?  Did you do anything
> >strange in the meantime?
> 
> I had just rebooted before I ran pvmove. The vg0 vg is definately a
> valid vg ... I think I ran vgscan during the process of trying to get it
> all to work, and nothing strange came up ...
> 
> I'll be away for the next couple of days, so I won't be recieving email
> during that time ...
> 
> Thanks,
> 
> Timshel

Ahh .... might help if the volume was actually active :-)

I kind of assumed that the volume would have to be inactive to move
physical extents ... you'll notice that I did a `vgchange -a n vg0' in
the script - I just moved my /var logical volume with no problems.

Maybe you want to document this a bit better ;-) I didn't notice
anything saying that the volume has to be active on the pvmove manpage
...

Thanks for your help,

Timshel

-- 
   Timshel Knoll <timshel@pobox.com>  for Debian email: <timshel@debian.org>
                Geomatics/Computer Science double degree, RMIT
      Debian GNU/Linux developer, see http://people.debian.org/~timshel/
                For GnuPG public key: finger timshel@debian.org