Bug 175682 - lvrename hangs on snapshot volume
Summary: lvrename hangs on snapshot volume
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel
Version: 4.0
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Alasdair Kergon
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-12-13 23:00 UTC by David Milburn
Modified: 2007-11-30 22:07 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-03-03 18:35:24 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description David Milburn 2005-12-13 23:00:06 UTC
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

Comment 1 Jonathan Earl Brassow 2005-12-14 20:18:24 UTC
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 21:20:14 UTC
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 20:02:57 UTC
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 22:28:58 UTC
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.