RE: [linux-lvm] LVM 1.0.4 pvmove is broken

RE: [linux-lvm] LVM 1.0.4 pvmove is broken

[Poul Petersen]

	I've done a lot of testing with pvmove and these are the results:

	1) The pvmove tool (versions 1.0.3, 1.0.4, 1.1-rc2) all fail on an
active volume group when running a LVM-1.0.4 patched 2.4.18 kernel

	2) If the volume group is inactive, pvmove works fine in all cases.

	3) The LVM-1.0.3 and 1.1-rc2 patches against the 2.4.18 kernel also
work fine with all versions of pvmove.

	4) The RedHat 7.2 call to vgscan in rc.sysinit happens before
mounting other file-systems, for example "/usr". This causes the 1.1-rc2
vgscan to fail since libreadline is in /usr/lib. 

	By using the -vv option to pvmove, I can see that pvmove is hanging
at lv_le_remap from tools/lib (see attached pvmove output) - this combined
with the strace output I posted before suggests that the ioctl call in
tools/lib/lv_le_remap.c is where it is dying. 

	I've tested this on three different machines (RedHat 7.1, 7.2) with
the same results, so I don't think I am doing anything wrong. There seems to
be something amiss in the Makefile generated patch for lvm-1.0.4 with kernel
2.4.18. I welcome any suggestions on how I can persue tracking this problem
down. I would like to use 1.0.4 as it is the latest stable release and I
intend to install it on a production machine, so I would like to avoid
1.1-rc2.

Thanks,

-poul

--- pvmove output 

[root@nfs1node1 root]# pvmove -vv /dev/sdb1
pvmove -- checking name of source physical volume "/dev/sdb1"
pvmove -- locking logical volume manager
pvmove -- reading data of source physical volume from "/dev/sdb1"
pvmove -- checking volume group existence
pvmove -- reading data of volume group "vg0" from lvmtab
pvmove -- checking volume group consistency of "vg0"
pvmove -- searching for source physical volume "/dev/sdb1" in volume group
"vg0"
pvmove -- building list of possible destination physical volumes
pvmove -- checking volume group activity
pvmove -- moving physical extents in active volume group "vg0"
pvmove -- WARNING: if you lose power during the move you may need to restore
your LVM metadata from backup!
pvmove -- do you want to continue? [y/n] y
pvmove -- starting to move extents away from physical volume "/dev/sdb1"
pvmove -- checking for enough free physical extents in "vg0" lv:
/dev/vg0/lv0[1]  old_dev: 08:17  new_dev: 08:18  old_pe_sector: 8576
new_pe_sector: 8576
pvmove -- opening output physical volume "/dev/sdb2"
pvmove -- llseeking input physical volume "/dev/sdb1"
pvmove -- llseeking output physical volume "/dev/sdb2"
pvmove -- /dev/sdb1 [PE 0 [lv0 [LE 0]] -> /dev/sdb2 [PE 0] [1/25]
pvmove -- locking physical extent 0 of "/dev/sdb1" in kernel
pvmove -- about to read input physical volume "/dev/sdb1" and to write
output physical volume "/dev/sdb2"
pvmove -- remapping physical extent in VGDA of kernel
pvmove -- unlocking physical extent
pvmove -- changing source "/dev/sdb1" in VGDA of kernel
pvmove -- changing destination "/dev/sdb2" in VGDA of kernel
pvmove -- writing physical extent part of VGDA on source "/dev/sdb1"
pvmove -- writing physical extent part of VGDA on destination "/dev/sdb2"
lv: /dev/vg0/lv0[1]  old_dev: 08:17  new_dev: 08:18  old_pe_sector: 16768
new_pe_sector: 16768
pvmove -- opening output physical volume "/dev/sdb2"
pvmove -- llseeking input physical volume "/dev/sdb1"
pvmove -- llseeking output physical volume "/dev/sdb2"
pvmove -- /dev/sdb1 [PE 1 [lv0 [LE 1]] -> /dev/sdb2 [PE 1] [2/25]
pvmove -- locking physical extent 1 of "/dev/sdb1" in kernel
pvmove -- about to read input physical volume "/dev/sdb1" and to write
output physical volume "/dev/sdb2"
pvmove -- remapping physical extent in VGDA of kernel

*This is where it dies*

Re: [linux-lvm] LVM 1.0.4 pvmove is broken

[Luca Berra]

On Wed, May 22, 2002 at 04:22:04PM -0700, Poul Petersen wrote:
> 	I've done a lot of testing with pvmove and these are the results:
> 
> 	1) The pvmove tool (versions 1.0.3, 1.0.4, 1.1-rc2) all fail on an
> active volume group when running a LVM-1.0.4 patched 2.4.18 kernel
since you are willing, did you try the pvmove patches that Stephen Tweedie
made a while ago? (he posted an url for those on the list) and they are
implemented in rh7.3 kernel and lvm tools.

L.

-- 
Luca Berra -- bluca@comedia.it
        Communication Media & Services S.r.l.
 /"\
 \ /     ASCII RIBBON CAMPAIGN
  X        AGAINST HTML MAIL
 / \

Re: [linux-lvm] LVM 1.0.4 pvmove is broken

[Joe Thornber]

Poul,

It is well known that pvmove of live volumes in LVM1 is broken for a
couple of reasons, the most obvious being the deadlock under memory
pressure that you are experiencing.

I would encourage you to try Stephen Tweedies patch and post your
findings.

In the longer term the solution is to move to LVM2; we are currently
working on pvmove and will have it in the next beta (beginning of
June), pvmove is the last major feature from LVM1 that LVM2 doesn't
yet support.

- Joe

Re: [linux-lvm] LVM 1.0.4 pvmove is broken

[Heinz J . Mauelshagen]

On Wed, May 22, 2002 at 04:22:04PM -0700, Poul Petersen wrote:
> 	I've done a lot of testing with pvmove and these are the results:
> 
> 	1) The pvmove tool (versions 1.0.3, 1.0.4, 1.1-rc2) all fail on an
> active volume group when running a LVM-1.0.4 patched 2.4.18 kernel
> 

Has that been under memory preasure as Joe assumed?

> 	2) If the volume group is inactive, pvmove works fine in all cases.
> 
> 	3) The LVM-1.0.3 and 1.1-rc2 patches against the 2.4.18 kernel also
> work fine with all versions of pvmove.
> 
> 	4) The RedHat 7.2 call to vgscan in rc.sysinit happens before
> mounting other file-systems, for example "/usr". This causes the 1.1-rc2
> vgscan to fail since libreadline is in /usr/lib. 

Posted the solution for such fs layouts recently
(Either use "./configure --disable-single_exec" or
 ./configure --enable-static_link).

> 
> 	By using the -vv option to pvmove, I can see that pvmove is hanging
> at lv_le_remap from tools/lib (see attached pvmove output) - this combined
> with the strace output I posted before suggests that the ioctl call in
> tools/lib/lv_le_remap.c is where it is dying. 
> 
> 	I've tested this on three different machines (RedHat 7.1, 7.2) with
> the same results, so I don't think I am doing anything wrong. There seems to
> be something amiss in the Makefile generated patch for lvm-1.0.4 with kernel
> 2.4.18. I welcome any suggestions on how I can persue tracking this problem
> down. I would like to use 1.0.4 as it is the latest stable release and I
> intend to install it on a production machine, so I would like to avoid
> 1.1-rc2.

Right, 1.1-rc is not for production purposes.

Your listing looks like you hit a lcking flaw in your configurations.

Will test your configurations on UP and SMP...

Regards,
Heinz    -- The LVM Guy --

> 
> Thanks,
> 
> -poul
> 
> --- pvmove output 
> 
> [root@nfs1node1 root]# pvmove -vv /dev/sdb1
> pvmove -- checking name of source physical volume "/dev/sdb1"
> pvmove -- locking logical volume manager
> pvmove -- reading data of source physical volume from "/dev/sdb1"
> pvmove -- checking volume group existence
> pvmove -- reading data of volume group "vg0" from lvmtab
> pvmove -- checking volume group consistency of "vg0"
> pvmove -- searching for source physical volume "/dev/sdb1" in volume group
> "vg0"
> pvmove -- building list of possible destination physical volumes
> pvmove -- checking volume group activity
> pvmove -- moving physical extents in active volume group "vg0"
> pvmove -- WARNING: if you lose power during the move you may need to restore
> your LVM metadata from backup!
> pvmove -- do you want to continue? [y/n] y
> pvmove -- starting to move extents away from physical volume "/dev/sdb1"
> pvmove -- checking for enough free physical extents in "vg0" lv:
> /dev/vg0/lv0[1]  old_dev: 08:17  new_dev: 08:18  old_pe_sector: 8576
> new_pe_sector: 8576
> pvmove -- opening output physical volume "/dev/sdb2"
> pvmove -- llseeking input physical volume "/dev/sdb1"
> pvmove -- llseeking output physical volume "/dev/sdb2"
> pvmove -- /dev/sdb1 [PE 0 [lv0 [LE 0]] -> /dev/sdb2 [PE 0] [1/25]
> pvmove -- locking physical extent 0 of "/dev/sdb1" in kernel
> pvmove -- about to read input physical volume "/dev/sdb1" and to write
> output physical volume "/dev/sdb2"
> pvmove -- remapping physical extent in VGDA of kernel
> pvmove -- unlocking physical extent
> pvmove -- changing source "/dev/sdb1" in VGDA of kernel
> pvmove -- changing destination "/dev/sdb2" in VGDA of kernel
> pvmove -- writing physical extent part of VGDA on source "/dev/sdb1"
> pvmove -- writing physical extent part of VGDA on destination "/dev/sdb2"
> lv: /dev/vg0/lv0[1]  old_dev: 08:17  new_dev: 08:18  old_pe_sector: 16768
> new_pe_sector: 16768
> pvmove -- opening output physical volume "/dev/sdb2"
> pvmove -- llseeking input physical volume "/dev/sdb1"
> pvmove -- llseeking output physical volume "/dev/sdb2"
> pvmove -- /dev/sdb1 [PE 1 [lv0 [LE 1]] -> /dev/sdb2 [PE 1] [2/25]
> pvmove -- locking physical extent 1 of "/dev/sdb1" in kernel
> pvmove -- about to read input physical volume "/dev/sdb1" and to write
> output physical volume "/dev/sdb2"
> pvmove -- remapping physical extent in VGDA of kernel
> 
> *This is where it dies*
> 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html

*** Software bugs are stupid.
    Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
Mauelshagen@Sistina.com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-lvm] LVM 1.0.4 pvmove is broken

[Heinz J . Mauelshagen]

Poul,

please try the  patch below which should fix the locking problem I
introduced in 1.0.4.

This is against a clean 2.4.18 kernel patched with LVM 1.0.4.

Regards,
Heinz    -- The LVM Guy --

--- linux-2.4.18-LVM-1.0.4/drivers/md/lvm.c     Fri May 24 15:03:22 2002
+++ linux-2.4.18-LVM-1.0.4.patched/drivers/md/lvm.c     Fri May 24 14:57:11 2002
@@ -1488,26 +1488,22 @@
                        continue;

                if (strcmp(lv_ptr->lv_name, le_remap_req.lv_name) == 0) {
-                       down_read(&lv_ptr->lv_lock);
+                       down_write(&lv_ptr->lv_lock);
                        for (le = 0; le < lv_ptr->lv_allocated_le; le++) {
                                if (lv_ptr->lv_current_pe[le].dev ==
                                    le_remap_req.old_dev &&
                                    lv_ptr->lv_current_pe[le].pe ==
                                    le_remap_req.old_pe) {
-                                       up_read(&lv_ptr->lv_lock);
-                                       down_write(&lv_ptr->lv_lock);
                                        lv_ptr->lv_current_pe[le].dev =
                                            le_remap_req.new_dev;
                                        lv_ptr->lv_current_pe[le].pe =
                                            le_remap_req.new_pe;
-                                       up_write(&lv_ptr->lv_lock);
-                                       down_read(&lv_ptr->lv_lock);
-
                                        __update_hardsectsize(lv_ptr);
+                                       up_write(&lv_ptr->lv_lock);
                                        return 0;
                                }
                        }
-                       up_read(&lv_ptr->lv_lock);
+                       up_write(&lv_ptr->lv_lock);
                        return -EINVAL;
                }
        }

On Wed, May 22, 2002 at 04:22:04PM -0700, Poul Petersen wrote:
> 	I've done a lot of testing with pvmove and these are the results:
> 
> 	1) The pvmove tool (versions 1.0.3, 1.0.4, 1.1-rc2) all fail on an
> active volume group when running a LVM-1.0.4 patched 2.4.18 kernel
> 
> 	2) If the volume group is inactive, pvmove works fine in all cases.
> 
> 	3) The LVM-1.0.3 and 1.1-rc2 patches against the 2.4.18 kernel also
> work fine with all versions of pvmove.
> 
> 	4) The RedHat 7.2 call to vgscan in rc.sysinit happens before
> mounting other file-systems, for example "/usr". This causes the 1.1-rc2
> vgscan to fail since libreadline is in /usr/lib. 
> 
> 	By using the -vv option to pvmove, I can see that pvmove is hanging
> at lv_le_remap from tools/lib (see attached pvmove output) - this combined
> with the strace output I posted before suggests that the ioctl call in
> tools/lib/lv_le_remap.c is where it is dying. 
> 
> 	I've tested this on three different machines (RedHat 7.1, 7.2) with
> the same results, so I don't think I am doing anything wrong. There seems to
> be something amiss in the Makefile generated patch for lvm-1.0.4 with kernel
> 2.4.18. I welcome any suggestions on how I can persue tracking this problem
> down. I would like to use 1.0.4 as it is the latest stable release and I
> intend to install it on a production machine, so I would like to avoid
> 1.1-rc2.
> 
> Thanks,
> 
> -poul
> 
> --- pvmove output 
> 
> [root@nfs1node1 root]# pvmove -vv /dev/sdb1
> pvmove -- checking name of source physical volume "/dev/sdb1"
> pvmove -- locking logical volume manager
> pvmove -- reading data of source physical volume from "/dev/sdb1"
> pvmove -- checking volume group existence
> pvmove -- reading data of volume group "vg0" from lvmtab
> pvmove -- checking volume group consistency of "vg0"
> pvmove -- searching for source physical volume "/dev/sdb1" in volume group
> "vg0"
> pvmove -- building list of possible destination physical volumes
> pvmove -- checking volume group activity
> pvmove -- moving physical extents in active volume group "vg0"
> pvmove -- WARNING: if you lose power during the move you may need to restore
> your LVM metadata from backup!
> pvmove -- do you want to continue? [y/n] y
> pvmove -- starting to move extents away from physical volume "/dev/sdb1"
> pvmove -- checking for enough free physical extents in "vg0" lv:
> /dev/vg0/lv0[1]  old_dev: 08:17  new_dev: 08:18  old_pe_sector: 8576
> new_pe_sector: 8576
> pvmove -- opening output physical volume "/dev/sdb2"
> pvmove -- llseeking input physical volume "/dev/sdb1"
> pvmove -- llseeking output physical volume "/dev/sdb2"
> pvmove -- /dev/sdb1 [PE 0 [lv0 [LE 0]] -> /dev/sdb2 [PE 0] [1/25]
> pvmove -- locking physical extent 0 of "/dev/sdb1" in kernel
> pvmove -- about to read input physical volume "/dev/sdb1" and to write
> output physical volume "/dev/sdb2"
> pvmove -- remapping physical extent in VGDA of kernel
> pvmove -- unlocking physical extent
> pvmove -- changing source "/dev/sdb1" in VGDA of kernel
> pvmove -- changing destination "/dev/sdb2" in VGDA of kernel
> pvmove -- writing physical extent part of VGDA on source "/dev/sdb1"
> pvmove -- writing physical extent part of VGDA on destination "/dev/sdb2"
> lv: /dev/vg0/lv0[1]  old_dev: 08:17  new_dev: 08:18  old_pe_sector: 16768
> new_pe_sector: 16768
> pvmove -- opening output physical volume "/dev/sdb2"
> pvmove -- llseeking input physical volume "/dev/sdb1"
> pvmove -- llseeking output physical volume "/dev/sdb2"
> pvmove -- /dev/sdb1 [PE 1 [lv0 [LE 1]] -> /dev/sdb2 [PE 1] [2/25]
> pvmove -- locking physical extent 1 of "/dev/sdb1" in kernel
> pvmove -- about to read input physical volume "/dev/sdb1" and to write
> output physical volume "/dev/sdb2"
> pvmove -- remapping physical extent in VGDA of kernel
> 
> *This is where it dies*
> 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html

*** Software bugs are stupid.
    Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
Mauelshagen@Sistina.com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

RE: [linux-lvm] LVM 1.0.4 pvmove is broken

[Poul Petersen]

> Poul,
> 
> please try the  patch below which should fix the locking problem I
> introduced in 1.0.4.
> 
> This is against a clean 2.4.18 kernel patched with LVM 1.0.4.
> 
> Regards,
> Heinz    -- The LVM Guy --

	That fixes it! Thanks!


-poul

Re: [linux-lvm] LVM 1.0.4 pvmove is broken

[Heinz J . Mauelshagen]

On Fri, May 24, 2002 at 09:03:44AM -0700, Poul Petersen wrote:
> > Poul,
> > 
> > please try the  patch below which should fix the locking problem I
> > introduced in 1.0.4.
> > 
> > This is against a clean 2.4.18 kernel patched with LVM 1.0.4.
> > 
> > Regards,
> > Heinz    -- The LVM Guy --
> 
> 	That fixes it! Thanks!

Alright. Is in CVS (LVM_BRANCH_1-0) and will show up in 1.0.5 soon.

> 
> 
> -poul
> 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html

-- 

Regards,
Heinz    -- The LVM Guy --

*** Software bugs are stupid.
    Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
Mauelshagen@Sistina.com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

RE: [linux-lvm] LVM 1.0.4 pvmove is broken

[Poul Petersen]

> It is well known that pvmove of live volumes in LVM1 is broken for a
> couple of reasons, the most obvious being the deadlock under memory
> pressure that you are experiencing.

	If it is so well know, should it be in the known_bugs for 1.0.4? I
saw
the following entries:

- There is a very slight change that pvmove on a live system can
  corrupt your data.  A pvmove on an offline (ie. not mounted) LV
  should be fine.

- There is also a chance under high load that a live pvmove will
  deadlock your system.

	However, what I have been seeing is not a "very slight chance"; it
fails
every time. Also, whether or not the LV is mounted doesn't matter - in all
of the
failures I have seen the LV was *not* mounted. The three critical failure
elements seem 
to be:

	1) use the LVM 1.0.4 Makefile generated patch for 2.4.18
	2) use 1.0.4 pvmove tool.
	3) Use an active VG, that is vgchange -ay

	As long as I do all three things, it will fail every time without
question 
on three different machines that I have tested. If I change any element, say
use the
1.0.3 toolset or use 1.0.4 but simply don't apply the Makefile generated
patch, then
it works fine. Is this still the same problem? Load is also not in question
- the
three machines I have tested were all in a lab environment, so there is no
concern 
about system load, lack of memory, etc. I guess what I am seeing is that if
I follow
the installation directions for 1.0.4 (apply the patch etc) then pvmove is
completely
broken. Is this right? Obviously I wouldn't want to have to deactivate the
entire VG
to move PEs around.

> I would encourage you to try Stephen Tweedies patch and post your
> findings.

	I will try that... Thanks for the pointer, I evidently missed that
post while
searching through the archives before. If pvmove is as broken as his post
suggests, I'll
probably just stay away from it - I only brought up this issue because the
way in which
I was seeing pvmove fail incessantly suggested that there might be a simple
fix.

> In the longer term the solution is to move to LVM2; we are currently
> working on pvmove and will have it in the next beta (beginning of
> June), pvmove is the last major feature from LVM1 that LVM2 doesn't
> yet support.

	Speaking of LVM2, will the transition to LVM2 require recreating the
VGs?


Thanks,

-poul

Re: [linux-lvm] LVM 1.0.4 pvmove is broken

[Joe Thornber]

On Thu, May 23, 2002 at 10:18:14AM -0700, Poul Petersen wrote:
> > It is well known that pvmove of live volumes in LVM1 is broken for a
> > couple of reasons, the most obvious being the deadlock under memory
> > pressure that you are experiencing.
> 
> 	If it is so well know, should it be in the known_bugs for 1.0.4? I
> saw
> the following entries:
> 
> - There is a very slight change that pvmove on a live system can
>   corrupt your data.  A pvmove on an offline (ie. not mounted) LV
>   should be fine.
> 
> - There is also a chance under high load that a live pvmove will
>   deadlock your system.
> 
> 	However, what I have been seeing is not a "very slight chance"; it
> fails
> every time. Also, whether or not the LV is mounted doesn't matter - in all
> of the
> failures I have seen the LV was *not* mounted. The three critical failure
> elements seem 
> to be:
> 
> 	1) use the LVM 1.0.4 Makefile generated patch for 2.4.18
> 	2) use 1.0.4 pvmove tool.
> 	3) Use an active VG, that is vgchange -ay
> 
> 	As long as I do all three things, it will fail every time without
> question 
> on three different machines that I have tested. If I change any element, say
> use the
> 1.0.3 toolset or use 1.0.4 but simply don't apply the Makefile generated
> patch, then
> it works fine. Is this still the same problem?

No, you have definitely hit a new problem introduced by 1.0.4.  Sorry
to mislead you.  I'm sure Heinz will get you a fix soon.

> > In the longer term the solution is to move to LVM2; we are currently
> > working on pvmove and will have it in the next beta (beginning of
> > June), pvmove is the last major feature from LVM1 that LVM2 doesn't
> > yet support.
> 
> 	Speaking of LVM2, will the transition to LVM2 require recreating the
> VGs?

No, LVM2 can use the same on disk format as LVM1.  Just build the
device-mapper into the kernel, build the LVM2 tools and reboot.  Or
you may wish to use Andres Salomon's Debian packages (search this list
for his post for where to get them).

- Joe

RE: [linux-lvm] LVM 1.0.4 pvmove is broken

[Poul Petersen]

> Poul,
> 
> couldn't reproduce this directly here.
> Need to investigate more...

	Thanks for looking into this - I verified my results on a third
machine, this one a single CPU P-III, 1Ghz running RedHat 7.2. In case I am
doing something really silly, these are the exact steps I did to reproduce
the problem - notice that /dev/hdc is a 10Gig disk which I partitioned into
two equal 5-gig partitions and tagged as type 8e:

unpack 2.4.18 kernel into /usr/src/linux-2.4.18_lvm-1.0.4
cd into LVM-1.0.4 source
./configure --with-kernel_dir=/usr/src/linux-2.4.18_lvm-1.0.4
cd PATCHES
make
cd into kernel source
patch -p1 < /usr/local/src/LVM/1.0.4/PATCHES/lvm-1.0.4-2.4.18.patch
make menuconfig
enable LVM as a module in Multiple devices driver support
disable sound card support
disable usb support
edit kernel Makefile and set EXTRAVERSION = _lvm-1.0.4
make dep && make && make modules && make modules_install
mkinitrd /boot/initrd-2.4.18_lvm-1.0.4.img 2.4.18_lvm-1.0.4
edit lilo.conf and add entry for new kernel
make install
cd into LVM-1.0.4 source
make
make install
reboot into new kernel, single-user mode
vgscan
pvcreate /dev/hdc1 /dev/hdc2
vgcreate vg0 /dev/hdc1 /dev/hdc2
lvcreate -L 100M -n lv0 vg0
vgdisplay -v (see below for output)
pvmove -v /dev/hdc1

	The pvmove asks if I am sure, moves one PE and then hangs. OK, I'm
ready to feel silly :)

Thanks again - everything else in LVM 1.0.4 is working great for me, but I
just can't get pvmove to work.

-poul

Output of vgdisplay -v:

--- Volume group ---
VG Name               vg0
VG Access             read/write
VG Status             available/resizable
VG #                  0
MAX LV                256
Cur LV                1
Open LV               0
MAX LV Size           255.99 GB
Max PV                256
Cur PV                2
Act PV                2
VG Size               9.52 GB
PE Size               4 MB
Total PE              2436
Alloc PE / Size       25 / 100 MB
Free  PE / Size       2411 / 9.42 GB
VG UUID               Qa6d0F-ATIc-5nIU-iL3X-e1Hj-2jpx-H8cPJN

--- Logical volume ---
LV Name                /dev/vg0/lv0
VG Name                vg0
LV Write Access        read/write
LV Status              available
LV #                   1
# open                 0
LV Size                100 MB
Current LE             25
Allocated LE           25
Allocation             next free
Read ahead sectors     1024
Block device           58:0


--- Physical volumes ---
PV Name (#)           /dev/hdc1 (1)
PV Status             available / allocatable
Total PE / Free PE    1218 / 1193

PV Name (#)           /dev/hdc2 (2)
PV Status             available / allocatable
Total PE / Free PE    1218 / 1218

RE: [linux-lvm] LVM 1.0.4 pvmove is broken

[Poul Petersen]

	I must be doing something wrong. I've tried this on a second machine
(a PII-333 running RedHat 7.1), with a single processor to rule out SMP
issues, and I had the same results. I also tried using a local IDE disk to
rule out any SCSI/SAN driver issues (both of these machines are connected to
a Zzyzx Raid Head via Qlogic 2200 Fibre Channel cards). I'm basically
unpacking the 2.4.18 kernel, applying the LVM patch, making a few small
changes to the kernel configuration to add network drivers, etc, and then
building. Nothing fancy. I have discovered that as long as the VG is not
active, the pvmove will function. If the VG is active, it will fail every
time on while moving the second PE. 

	I ran pvmove with strace and this is where it hangs (The "..."
represents the llseek/read/write blocks that I removed)

write(1, "pvmove -- /dev/sdb [PE 305 [lv0 "..., 67pvmove -- /dev/sdb [PE 305
[lv0
[LE 0]] -> /dev/sdc [PE 0] [1/306]
) = 67
open("/dev/vg0/group", O_RDONLY)        = 6
ioctl(6, 0x4004fe50, 0xbffff1e0)        = 0
close(6)                                = 0
_llseek(4, 0, [1283719168], SEEK_CUR)   = 0
read(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 65536)
= 65536
write(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 65536)
= 65536
...
read(4, "\306\35\2\206\241\353?;\202\303ED\2306s\16\217\10\236\241"...,
65536) = 65536
write(5, "\306\35\2\206\241\353?;\202\303ED\2306s\16\217\10\236\241"...,
65536) = 65536
fsync(5)                                = 0
open("/dev/vg0/group", O_RDWR)          = 6
ioctl(6, 0x4004fe2b

	I'm going to try a different kernel - I was using 2.4.18 because I
wanted to eventually use XFS-1.1.

Thanks for any help,

-poul

> -----Original Message-----
> From: Heinz J . Mauelshagen [mailto:mauelshagen@sistina.com]
> Sent: Friday, May 10, 2002 6:39 AM
> To: linux-lvm@sistina.com
> Subject: Re: [linux-lvm] LVM 1.0.4 pvmove is broken
> 
> 
> 
> Poul,
> 
> couldn't reproduce this directly here.
> Need to investigate more...
> 
> On Thu, May 09, 2002 at 02:49:40PM -0700, Poul Petersen wrote:
> > 	I posted a day or two ago, and as near as I can tell 
> pvmove in LVM
> > 1.0.4 with kernel 2.4.18 is broken. If I apply the 1.0.4 
> patch generated by
> > PATCHES/Makefile to a stock 2.4.18 kernel, pvmove will 
> crash after moving
> > one PE, every time, regardless of the arrangement of 
> physical volumes,
> > filesystems, etc. Notice that this failure occurs even 
> without a filesystem
> > present in the logical volume, that is I can make a volume 
> group with two
> > disks, create a small LV and pvmove will crash trying to 
> move the PEs. If I
> > follow the exact same installation procedure for LVM 1.0.3, 
> everything works
> > fine. If I use the 1.0.4 toolset with an unpatched stock 
> 2.4.18 kernel,
> > everything works fine. The problem with pvmove is 
> definitely precipitated by
> > installing the auto-generated patch from 1.0.4. 
> > 
> > 	Is this working for anyone else? I didn't want to attach the
> > auto-generated patch since it is 70k, but I can provide it 
> if it would help.
> > 
> > Thanks,
> > 
> > -poul
> > 
> > System Specs:
> > RedHat 7.2 w/ 2.4.18 kernel
> > Dual P-II 400 
> > 
> > 
> > _______________________________________________
> > linux-lvm mailing list
> > linux-lvm@sistina.com
> > http://lists.sistina.com/mailman/listinfo/linux-lvm
> > read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
> 
> -- 
> 
> Regards,
> Heinz    -- The LVM Guy --
> 
> *** Software bugs are stupid.
>     Nevertheless it needs not so stupid people to solve them ***
> 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> =-=-=-=-=-=-=-=-
> 
> Heinz Mauelshagen                                 Sistina 
> Software Inc.
> Senior Consultant/Developer                       Am Sonnenhang 11
>                                                   56242 Marienrachdorf
>                                                   Germany
> Mauelshagen@Sistina.com                           +49 2626 141200
>                                                        FAX 924446
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> =-=-=-=-=-=-=-=-
> 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
> 

[linux-lvm] LVM 1.0.4 pvmove is broken

[Poul Petersen]

	I posted a day or two ago, and as near as I can tell pvmove in LVM
1.0.4 with kernel 2.4.18 is broken. If I apply the 1.0.4 patch generated by
PATCHES/Makefile to a stock 2.4.18 kernel, pvmove will crash after moving
one PE, every time, regardless of the arrangement of physical volumes,
filesystems, etc. Notice that this failure occurs even without a filesystem
present in the logical volume, that is I can make a volume group with two
disks, create a small LV and pvmove will crash trying to move the PEs. If I
follow the exact same installation procedure for LVM 1.0.3, everything works
fine. If I use the 1.0.4 toolset with an unpatched stock 2.4.18 kernel,
everything works fine. The problem with pvmove is definitely precipitated by
installing the auto-generated patch from 1.0.4. 

	Is this working for anyone else? I didn't want to attach the
auto-generated patch since it is 70k, but I can provide it if it would help.

Thanks,

-poul

System Specs:
RedHat 7.2 w/ 2.4.18 kernel
Dual P-II 400 

Re: [linux-lvm] LVM 1.0.4 pvmove is broken

[Heinz J . Mauelshagen]

Poul,

couldn't reproduce this directly here.
Need to investigate more...

On Thu, May 09, 2002 at 02:49:40PM -0700, Poul Petersen wrote:
> 	I posted a day or two ago, and as near as I can tell pvmove in LVM
> 1.0.4 with kernel 2.4.18 is broken. If I apply the 1.0.4 patch generated by
> PATCHES/Makefile to a stock 2.4.18 kernel, pvmove will crash after moving
> one PE, every time, regardless of the arrangement of physical volumes,
> filesystems, etc. Notice that this failure occurs even without a filesystem
> present in the logical volume, that is I can make a volume group with two
> disks, create a small LV and pvmove will crash trying to move the PEs. If I
> follow the exact same installation procedure for LVM 1.0.3, everything works
> fine. If I use the 1.0.4 toolset with an unpatched stock 2.4.18 kernel,
> everything works fine. The problem with pvmove is definitely precipitated by
> installing the auto-generated patch from 1.0.4. 
> 
> 	Is this working for anyone else? I didn't want to attach the
> auto-generated patch since it is 70k, but I can provide it if it would help.
> 
> Thanks,
> 
> -poul
> 
> System Specs:
> RedHat 7.2 w/ 2.4.18 kernel
> Dual P-II 400 
> 
> 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html

-- 

Regards,
Heinz    -- The LVM Guy --

*** Software bugs are stupid.
    Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
Mauelshagen@Sistina.com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-