Red Hat Bugzilla – Bug 175682
lvrename hangs on snapshot volume
Last modified: 2007-11-30 17:07:22 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc3 Firefox/1.0.7 Description of problem: Renaming a LVM snapshot causes the lvrename process to hang, it cannot be killed with Ctrl-c, it also prevents the system from being rebooted with "/sbin/reboot" or "/sbin/shutdown -r". This problem has been reported on the 2.6.10 kernel. See: http://www.redhat.com/archives/dm-devel/2005-January/msg00000.html Version-Release number of selected component (if applicable): kernel-smp-2.6.9-22.0.1.EL How reproducible: Always Steps to Reproduce: 1. pvcreate /dev/sda1 2. vgcreate testvg /dev/sda1 3. lvcreate -L10G -n test testvg 4. mke2fs -j /dev/mapper/testvg-test 5. mount /dev/mapper/testvg-test /mnt 6. lvcreate -s -l 128 -n test_backup testvg/test 7. lvrename testvg test_backup test_backup.tmp Actual Results: The lvrename command hangs, and the system cannot be rebooted. Expected Results: Should be able to rename the snapshot. Additional info: Here is sysrq-t data for lvrename when it is in the hung state. lvrename D DEA119B0 2196 4073 4034 (NOTLB) d0170ec0 00200082 d5a50c80 dea119b0 c02232e4 013ffff8 00000000 00000008 ce213f00 00200046 c1417d60 00000002 00040650 4b7aa2bf 00000039 dfeb0b30 dd67c2b0 dd67c41c e082f8af 00000008 c1417d60 c043af00 dfe1c580 d0170ecc Call Trace: [<c02232e4>] generic_make_request+0x18e/0x19e [<e082f8af>] dm_unplug_all+0x17/0x21 [dm_mod] [<c02cf67b>] io_schedule+0x26/0x30 [<c015ac10>] __wait_on_buffer+0x6c/0x83 [<c015aab8>] bh_wake_function+0x0/0x29 [<c015d8cd>] submit_bh+0x15a/0x166 [<c015aab8>] bh_wake_function+0x0/0x29 [<c015d9ef>] sync_dirty_buffer+0xa4/0xd4 [<e08bd93f>] ext3_unlockfs+0x51/0x73 [ext3] [<c015af0c>] thaw_bdev+0x28/0x61 [<e0830061>] unlock_fs+0x14/0x35 [dm_mod] [<e08302f8>] dm_resume+0xbb/0xe5 [dm_mod] [<e0832d0e>] do_resume+0x150/0x170 [dm_mod] [<e0833c93>] ctl_ioctl+0xd1/0x144 [dm_mod] [<e0832d2e>] dev_suspend+0x0/0x10 [dm_mod] [<c0169902>] sys_ioctl+0x227/0x269 [<c02d0fb7>] syscall_call+0x7/0xb [<c02d007b>] __lock_text_end+0x232/0x100f
works for me on 2.6.9-25.EL It seems to work on older kernels too, but more extensive testing is blocked by other snapshot bugs in earlier kernels
The rename code has changed in U3 (does fewer dm ioctls), so any attempt at reproducing this the same failure should use an older lvm2 package. If it can be reproduced with the new lvm2 package on the latest U3 kernel, then it is likely to be the same as bug 174636. (Both lock up inside filesystem syncs.)
Previously, I had reproduced the problem on a system running 2.6.9-22.0.1.ELsmp and lvm2-2.01.14-2.0.RHEL4. I upgraded to 2.6.9-25.ELsmp and was able to reproduce the hang. But after upgrading to lvm2-2.02-01-1.1.RHEL4, I was no longer able to reproduce the hang running the 2.6.9-25.ELsmp kernel.
FYI: this works for me with the latest and greatest lvm2/device-mapper. I'll add a check for this in the regression tests though.