Bug 192924 - FC5 lvcreate -s dosen't create snapshot, but create normal lv
Summary: FC5 lvcreate -s dosen't create snapshot, but create normal lv
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: lvm2
Version: 5
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Alasdair Kergon
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-05-24 09:22 UTC by Kazutoshi Morioka
Modified: 2007-11-30 22:11 UTC (History)
4 users (show)

Fixed In Version: kernel 2.6.18
Clone Of:
Environment:
Last Closed: 2006-09-26 07:15:42 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Kazutoshi Morioka 2006-05-24 09:22:43 UTC
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.

Comment 1 Kazutoshi Morioka 2006-05-24 12:27:58 UTC
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) (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.

Comment 2 Alasdair Kergon 2006-06-02 14:54:43 UTC
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.

Comment 3 Kazutoshi Morioka 2006-06-02 15:35:02 UTC
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

Comment 4 Kazutoshi Morioka 2006-06-21 06:10:09 UTC
2.6.17-1.2138_FC5 shows same problem.

Comment 5 Kazutoshi Morioka 2006-07-08 02:59:54 UTC
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.

Comment 6 Kazutoshi Morioka 2006-09-25 23:58:46 UTC
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.

Comment 7 Alasdair Kergon 2006-09-26 07:15:42 UTC
OK, thanks for letting us know.

Comment 8 David Nadle 2006-10-21 19:15:40 UTC
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. 








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