Skip to contentSkip to conversation

pvmove failure ...

linux-lvm Timshel Knoll 3 participants 6 messages Jun 8, 2001 – Jun 9, 2001

lore
Share & tools
lore

Timshel Knoll

author
#0 lore raw

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

Signature · 4 lines
   Timshel Knoll <[email protected]>  for Debian email: <[email protected]>
                Geomatics/Computer Science double degree, RMIT
      Debian GNU/Linux developer, see http://people.debian.org/~timshel/
                For GnuPG public key: finger [email protected]
#1 lore raw
Quoted 9 lines · Timshel Knoll

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

Quoted 7 lines

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,

Signature · 13 lines
AJ Lewis
Sistina Software Inc.                  Voice:  612-638-0500
1313 5th St SE, Suite 111              Fax:    612-638-0500
Minneapolis, MN 55414                  E-Mail: [email protected]
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------------------------------------------
#2 lore raw
In reply to Timshel Knoll
Quoted 8 lines · Timshel

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]

Quoted 4 lines

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

Signature · 3 lines
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
author
#3 lore raw
In reply to 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]

Quoted 7 lines

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

Signature · 4 lines
   Timshel Knoll <[email protected]>  for Debian email: <[email protected]>
                Geomatics/Computer Science double degree, RMIT
      Debian GNU/Linux developer, see http://people.debian.org/~timshel/
                For GnuPG public key: finger [email protected]
author
#4 lore raw
In reply to Timshel Knoll

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

Quoted 10 lines

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

Signature · 4 lines
   Timshel Knoll <[email protected]>  for Debian email: <[email protected]>
                Geomatics/Computer Science double degree, RMIT
      Debian GNU/Linux developer, see http://people.debian.org/~timshel/
                For GnuPG public key: finger [email protected]
author
#5 lore raw

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

Quoted 17 lines · Timshel Knoll

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

Quoted 10 lines

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

Quoted 6 lines

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

Signature · 4 lines
   Timshel Knoll <[email protected]>  for Debian email: <[email protected]>
                Geomatics/Computer Science double degree, RMIT
      Debian GNU/Linux developer, see http://people.debian.org/~timshel/
                For GnuPG public key: finger [email protected]