Merging LVM snapshots - what went wrong?

SUSE Product Topics SLES Configure-Administer
1

I’ve been playing with LVM snapshots. Somehow, things never go quite as
planned. I’m hoping someone can explain why.

I have an LV /dev/vg100/v101. I created a snapshot.

lvcreate -s -L 3G -n v101-snap /dev/vg100/v101

The original LV and snapshot were mounted and I copied a file into the
original LV v101. I saw it there but not in v101-snap, as expected.

I "umount"ed the snapshot LV v101-snap. Now I wanted to revert the
change to v101. The first time I tried, nothing seemed to happen. The
second time I tried, I got this:

server:~ # lvconvert --merge -v /dev/vg100/v101-snap
Using logical volume(s) on command line
Archiving volume group "vg100" metadata (seqno 41).
Snapshot v101-snap is already merging
Unable to merge LV "v101-snap" into its origin.

I couldn’t umount the original LV v101. IIRC, the volume was busy.
After rebooting the server I thought I’d try my test again. The file I
copied into v101 was no longer there but when I tried to create the
snapshot this time, I was told it already existed.

This is what I have learned:

server:~ # cat /etc/*release
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 2
LSB_VERSION="core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-x8
6_64:core-3.2-x86_64:core-4.0-x86_64"

server:~ # lvcreate -s -L 3G -n v101-snap /dev/vg100/v101
Logical volume "v101-snap" already exists in volume group "vg100"

server:~ # ls /dev/vg100/v101*
/dev/vg100/v101

server:~ # ls /dev/mapper/vg100-v101*
/dev/mapper/vg100-v101  /dev/mapper/vg100-v101--snap
/dev/mapper/vg100-v101--snap-cow  /dev/mapper/vg100-v101-real

server:~ # dmsetup info

Name:              vg100-v101
State:             ACTIVE
Read Ahead:        1024
Tables present:    LIVE
Open count:        1
Event number:      0
Major, minor:      253, 11
Number of targets: 1
UUID: LVM-.....

Name:              vg100-v101--snap-cow
State:             ACTIVE
Read Ahead:        1024
Tables present:    LIVE
Open count:        1
Event number:      0
Major, minor:      253, 10
Number of targets: 1
UUID: LVM-.....

Name:              vg100-v101--snap
State:             ACTIVE
Read Ahead:        1024
Tables present:    LIVE
Open count:        0
Event number:      0
Major, minor:      253, 12
Number of targets: 1
UUID: LVM-.....

Name:              vg100-v101-real
State:             ACTIVE
Read Ahead:        1024
Tables present:    LIVE
Open count:        1
Event number:      0
Major, minor:      253, 9
Number of targets: 1
UUID: LVM-.....

server:~ # lvdisplay /dev/vg100/v101
--- Logical volume ---
LV Name                /dev/vg100/v101
VG Name                vg100
LV UUID                .....
LV Write Access        read/write
LV snapshot status     source of
/dev/vg100/v101-snap [active]
LV Status              available
# open                 1
LV Size                70.00 GiB
Current LE             17920
Segments               1
Allocation             inherit
Read ahead sectors     auto
- currently set to     1024
Block device           253:11

Here are my questions:

Why didn’t the “lvconvert --merge” not seem to work until after the
system was rebooted? Would anyone care to speculate?

My snapshot LV was v101-snap but I now see:
vg100-v101–snap-cow,
vg100-v101–snap, and
vg100-v101-real
What are these objects?

What do I need to do to clean up these remnants and make v101-snap
disappear?

If necessary, I can open an SR…

–
Kevin Boyle - Knowledge Partner
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…

2

[QUOTE=KBOYLE;13472]…
I couldn’t umount the original LV v101. IIRC, the volume was busy.
After rebooting the server I thought I’d try my test again. The file I
copied into v101 was no longer there but when I tried to create the
snapshot this time, I was told it already existed…[/QUOTE]

Allot of strangeness there :confused:

I’ve used LV snapshots now a couple of times to revert test VM’s on Xen (where I have the VM’s OS disk phy connected to an LVM volume on the Xen host). I have not seen any real issues with this, other than the speed of writing back the snapshot info into the parent not always being as quick as hoped (sometimes just restoring a previous dd dump could be quicker depending on how much was written to the snapshot).

One thing that is important, is to make sure both parent as also snapshot volume are not held open by any process (open count on 0). The merge action will be queued as long as both volumes are not in a closed state. Could that maybe be why it was not working for you?

As this is a test scenario… I’m curious what will happen if you simply lvremove vg100-v101–snap-cow & vg100-v101-real and restart the ‘lvconvert --merge’?
Also, what size is reported in use by those volumes?

Cheers,
Willem

3

Magic31 wrote:
[color=blue]

KBOYLE;13472 Wrote:[color=green]

…
I couldn’t umount the original LV v101. IIRC, the volume was busy.
After rebooting the server I thought I’d try my test again. The
file I copied into v101 was no longer there but when I tried to
create the snapshot this time, I was told it already existed…[/color]

Allot of strangeness there :confused:

I’ve used LV snapshots now a couple of times to revert test VM’s on
Xen (where I have the VM’s OS disk phy connected to an LVM volume on
the Xen host). I have not seen any real issues with this, other than
the speed of writing back the snapshot info into the parent not
always being as quick as hoped (sometimes just restoring a previous
dd dump could be quicker depending on how much was written to the
snapshot).[/color]

That was my plan. I thought I’d test it out on an unimportant LV in my
Dom0 first.
[color=blue]

One thing that is important, is to make sure both parent as also
snapshot volume are not held open by any process (open count on 0).
The merge action will be queued as long as both volumes are not in a
closed state. Could that maybe be why it was not working for you?[/color]

I didn’t check that, not that I expected copying a small file would
have a serious impact.
[color=blue]

As this is a test scenario…[/color]

…but not on a test server. :frowning:
[color=blue]

I’m curious what will happen if you
simply lvremove vg100-v101–snap-cow & vg100-v101-real and restart the
‘lvconvert --merge’?[/color]

So am I… but they aren’t LV’s and only appear under /dev/mapper/
[color=blue]

Also, what size is reported in use by those volumes?[/color]

server:~ # lvscan --all
ACTIVE            '/dev/vg200/v200' [1.33 TiB] inherit
ACTIVE            '/dev/vg100/v102' [50.00 GiB] inherit
ACTIVE            '/dev/vg100/v103' [60.00 GiB] inherit
ACTIVE            '/dev/vg100/v104' [60.00 GiB] inherit
ACTIVE            '/dev/vg100/v105' [80.00 GiB] inherit
ACTIVE            '/dev/vg100/v107' [25.00 GiB] inherit
ACTIVE            '/dev/vg100/v108' [25.00 GiB] inherit
ACTIVE            '/dev/vg100/v109' [25.00 GiB] inherit
ACTIVE            '/dev/vg100/v105bak' [80.00 GiB] inherit
ACTIVE   Original '/dev/vg100/v101' [70.00 GiB] inherit
ACTIVE   Snapshot '/dev/vg100/v101-snap' [3.00 GiB] inherit

server:~ # ls /dev/vg100/
v101  v102  v103  v104  v105  v105bak  v107  v108  v109

server:~ #

Do snapshot LV’s usually show up under the VG? I don’t see it there.

Some of this stuff may be part of the metadata.

A lot of strangeness here…

[color=blue]

Cheers,
Willem[/color]

–
Kevin Boyle - Knowledge Partner
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…