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 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- _______________________________________________ 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