Bug 175682 - lvrename hangs on snapshot volume
lvrename hangs on snapshot volume
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Alasdair Kergon
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-12-13 18:00 EST by David Milburn
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-03-03 13:35:24 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David Milburn 2005-12-13 18:00:06 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):

How reproducible:

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
Comment 1 Jonathan Earl Brassow 2005-12-14 15:18:24 EST
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
Comment 2 Alasdair Kergon 2005-12-14 16:20:14 EST
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.)
Comment 3 David Milburn 2005-12-16 15:02:57 EST
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.
Comment 4 Corey Marthaler 2006-02-02 17:28:58 EST
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.

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