Hide Forgot
Description of problem: FC5 lvcreate -s dosen't create snapshot with this error # lvcreate -L1G -n test myvg Logical volume "test" created This created /dev/myvg/snap is not a snapshot, but a normal logical volume. # lvcreate -s -L 500M -n snap /dev/myvg/test LV myvg/snap in use: not deactivating Couldn't deactivate new snapshot. # lvs LV VG Attr LSize Origin Snap% Move Log Copy% snap myvg -wi-a- 500.00M test myvg -wi-a- 1.00G After origin-lv was deactivated, and sync, then the snapshot was created successfully # lvremove /dev/myvg/snap Do you really want to remove active logical volume "snap"? [y/n]: y Logical volume "snap" successfully removed # lvchange -a n /dev/myvg/test # sync ; sync ; sync # lvcreate -s -L 500M -n snap /dev/myvg/test Logical volume "snap" created # lvs LV VG Attr LSize Origin Snap% Move Log Copy% snap myvg swi--- 500.00M test test myvg owi--- 1.00G Version-Release number of selected component (if applicable): lvm2-2.02.01-1.2.1 from kernel-2.6.15-1.2054_FC5 to kernel-2.6.16-1.2122_FC5 How reproducible: always Steps to Reproduce: 1. lvcreate -L1G -n test VGNAME 2. lvcreate -s -L 500M -n snap /dev/VGNAME/test Actual results: this error was shown and normal lv was created. "LV myvg/snap in use: not deactivating Couldn't deactivate new snapshot." Expected results: a snapshot of origin lv was created. Additional info: On Fedora Core 4, a snapshot was created successfully with kernel-2.6.16-1.2111_FC4.i686 and lvm2-2.02.06.
I tested first on my PC with Celeron 950MHz. This box always shows this problem. I also tested on my another PC with Athlon 64 3000. On this faster PC also shows this problem, but a bit harder to reproduce. The problem never occurs when idle state. But while I was running "badblocks -vv /dev/hda", the problem occurs constantly. I compiled 2.6.16-1.2122_FC5 with gcc32: Linux version 2.6.16-1.2122_FC5.gcc32 (morioka@curry.local) (gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-55.fc5)) #1 Wed May 24 20:35:25 JST 2006 And this kernel also shows same problem.
There've been some reports of similar problems on Debian, apparently related to udev - we think udev might be holding a reference on the device at the instant lvm2 tries to remove it causing the removal to fail. [lvm2 temporarily activates the 'cow' device to fill the start of it with zeros] There are also some kernel device-mapper patches upstream (scheduled for 2.6.18 when it opens - currently in -mm) that deal with some races on device creation and might help.
I confirmed that after "udevcontrol stop_exec_queue", snapshot was always created successfully. Thanks. This can be an effective workaround. # udevcontrol stop_exec_queue # lvcreate -s -L 500M -n snap /dev/VGNAME/test # udevcontrol start_exec_queue
2.6.17-1.2138_FC5 shows same problem.
Today I tested this on rawhide and found that rawhide never shows this problem. Tested kernel was 2.6.17-1.2339.fc6, 2.6.17-1.2356.fc6 and 2.6.17-1.2358.fc6PAE. I don't know what time this was fixed. At least, when I was filed #192924, rawhide showed same problem.
Today's updates-testing for FC5, 2.6.18-1.2189.fc5 wiped out this problem. So, I think this bug can be closed. Thank you.
OK, thanks for letting us know.
This may have to be reopened. I'm seeing the problem in 2.6.18-1.2200.fc5. I have a backup script that creates four snapsnots: lvcreate -L 512M -s -n snapXX /dev/VolGroup00/LogVolXX Where XX is 00, 01, 02, 03. 00 and 02 always succeed. 01 and 03 always fail with the message: LV VolGroup00/snapXX in use: not deactivating Couldn't deactivate new snapsnot. lvs displays the following: LV VG Attr LSize Origin Snap% Move Log Copy% LogVol00 VolGroup00 owi-ao 10.00G LogVol01 VolGroup00 -wi-ao 20.00G LogVol02 VolGroup00 owi-ao 20.00G LogVol03 VolGroup00 -wi-ao 40.00G snap00 VolGroup00 swi-a- 512.00M LogVol00 3.20 snap01 VolGroup00 -wi-a- 512.00M snap02 VolGroup00 swi-a- 512.00M LogVol02 2.03 snap03 VolGroup00 -wi-a- 512.00M The udevcontrol workaround described in Comment #3 does work. After wrapping my four lvcreate lines with the udevcontrol commands all four snapshots were created successfully.