This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 122991 - pvmove needs ability to split contiguous data [NEEDINFO]
pvmove needs ability to split contiguous data
Status: ASSIGNED
Product: Fedora
Classification: Fedora
Component: lvm2 (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: LVM and device-mapper development team
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-05-11 02:46 EDT by Alexandre Oliva
Modified: 2014-11-26 07:22 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-08-12 11:50:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
zkabelac: needinfo? (oliva)


Attachments (Terms of Use)

  None (edit)
Description Alexandre Oliva 2004-05-11 02:46:44 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040506

Description of problem:
I was trying to implement pvmoving of specific extents (i.e., pvmove
PVfrom:extent PVto:extend, as available with lvm1 tools), but ran into
an ugly problem with the lvm2 tools that we ship: I can't seem to get
pvmove to work at all.

I created a pair of physical volumes on loopback devices (200+ 4MiB
extents each), a volume group out of them, and a 1-extent logical
volume.  Then, I attempted to pvmove this physical volume.

With lvm1, it just outright fails, since apparently lvm1 metadata
doesn't support mirror stripes.

With lvm2, it sets up a new logical volume with one extent, but then
it fails with the error message below.

Version-Release number of selected component (if applicable):
lvm2-2.00.15-2

How reproducible:
Always

Steps to Reproduce:
1.dd if=/dev/zero of=/tmp/loop0 bs=4096k count=10; dd if=/dev/zero
of=/tmp/loop1 bs=4096k count=10; losetup /dev/loop0 /tmp/loop0;
losetup /dev/loop1 /tmp/loop1
2.pvcreate /dev/loop[01]; vgcreate loop /dev/loop[01]; lvcreate -n
test -l 1 loop /dev/loop0
3.pvmove /dev/loop0

Actual Results:    device-mapper ioctl cmd 9 failed: Invalid argument
  Couldn't load device 'loop-pvmove0'.
  ABORTING: Temporary mirror activation failed.
  device-mapper ioctl cmd 9 failed: Invalid argument
  Couldn't load device 'loop-test'.

And then both test and pvmove0 are locked, I can't lvremove them any
more, and the only way out is to use vgcfgrestore to go back to what
was there before it messed things up.

Expected Results:  I expected it to work.  pvmove is an essential
feature of LVM IMHO.

Additional info:
Comment 1 Alasdair Kergon 2004-05-26 12:36:01 EDT
pvmove --abort is required to clean things up.

Presumably the device-mapper pvmove support has not made it into the
Fedora kernel yet.  We plan to submit it upstream fairly soon now.

The current upstream LVM2 release (2.00.16) contains code that detects
this problem in advance and gives an error message sooner, but I've no
intention of backporting that code to 2.00.15 - it'll have to wait
till Fedora is unfrozen.  (2.00.16 contains a lot of code changes, so
it could have introduced new bugs.)
Comment 2 Graham King 2004-07-12 18:38:30 EDT
FWIW, I get a very similar error, with  kernel 2.6.6-1.435.2.3smp and
lvm2-2.00.15-2 :

pvmove -v --name /dev/vgob00/lv_rawvm /dev/hda1 /dev/sdc3
  /dev/cdrom: open failed: No medium found
    Finding volume group "vgob00"
    Archiving volume group "vgob00" metadata.
    Creating logical volume pvmove0
    Moving 1000 extents of logical volume vgob00/lv_rawvm
    Found volume group "vgob00"
    Found volume group "vgob00"
    Updating volume group metadata
    Creating volume group backup "/etc/lvm/backup/vgob00"
    Found volume group "vgob00"
    Found volume group "vgob00"
    Loading vgob00-pvmove0
  device-mapper ioctl cmd 9 failed: Invalid argument
  Couldn't load device 'vgob00-pvmove0'.
  ABORTING: Temporary mirror activation failed.
    Found volume group "vgob00"
    Loading vgob00-lv_rawvm
  device-mapper ioctl cmd 9 failed: Invalid argument
  Couldn't load device 'vgob00-lv_rawvm'.

Many thanks for the tip about pvmove --abort 
Comment 3 Alasdair Kergon 2004-08-12 11:48:13 EDT
mirror support is in now - but the existence check to clean up the
above error sequence means you need to modprobe to install it before
you can use it...
Comment 4 Alexandre Oliva 2004-09-05 07:11:19 EDT
pvmove still doesn't work in current rawhide.  Here are the remaining
problems:

- it won't modprobe dm-mirror, and will error out with a message that
doesn't make it obvious that this is the module to be loaded.  Might
as well load it itself.

- even in test mode, it (says it) creates a logical volume for the
move, and errors out saying you have to abort

- on at least one box, it failed because it couldn't allocate a
contiguous sequence of extents, even though there was plenty of space
in the target physical volume (although definitely not contiguous)

- on a box that had enough contiguous extents, and on the original
box, after narrowing the source extent range such that there are
contiguous extents for pvmove, it started, but the kernel
(2.6.8-1.541) immediately froze, and then I couldn't reboot because
lvm as run by initrd failed to bring up the pvmove volume, and then
couldn't mount the root filesystem, on the same volume group.

I think I have enough grounds to reopen this ;-)
Comment 5 Alexandre Oliva 2004-09-05 08:27:00 EDT
Oddly, as soon as I booted the FC2 rescue CD, ran lvm vgscan and lvm
pvmove --abort and rebooted into rawhide, pvmove started working
(except for the need for explicit modprobing of dm-mirror and for
contiguous extents).  I haven't tried test mode any more.
Comment 6 Alasdair Kergon 2004-09-14 11:25:31 EDT
There's now a check for lvm1 metadata so it won't attempt the pvmove.

I've suppressed that particular ABORTING message for test mode as
several people have found it confusing.

Test mode is supposed to follow exactly the same code path as the
normal command as far as possible, except that writes and activations
are suppressed - but return success nevertheless.
Comment 7 Alasdair Kergon 2004-09-14 11:30:43 EDT
Outstanding requests:
  1) Would like the mirror/snapshot target presence checks extending
to try to load them too;
  2) Need more-sophisticated allocation code.
Comment 8 Alasdair Kergon 2006-03-08 10:31:24 EST
1) got fixed.

2) is still unfinished - updating this bugzilla to cover it.
Comment 10 Alasdair Kergon 2010-04-27 09:19:42 EDT
Still not done.
Comment 11 Zdenek Kabelac 2014-11-26 07:22:35 EST
It's now over 10 years ;) - is there anything still missing ?

Note You need to log in before you can comment on or make changes to this bug.