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