[linux-lvm] Snapshot removal fails first time under RAID

[linux-lvm] Snapshot removal fails first time under RAID

[Philip Boulain]

We have a Debian Wheezy server using mirrored RAID running kernel
3.2.0-1-amd64 and LVM version�2.02.88-2. There seems to be an issue
where snapshot removal fails due to being "in use" the first time, but
repeating the operation will succeed:

# lvcreate --size 128M --name testvolume buildturbo64
� Logical volume "testvolume" created
# lvcreate --size 128M --snapshot --name testsnap buildturbo64/testvolume
� Logical volume "testsnap" created
# lvremove buildturbo64/testsnap
Do you really want to remove active logical volume testsnap? [y/n]: y
� LV buildturbo64/testsnap in use: not deactivating
� Unable to deactivate logical volume "testsnap"
# lvremove buildturbo64/testsnap
Do you really want to remove active logical volume testsnap? [y/n]: y
� Logical volume "testsnap" successfully removed
# lvremove buildturbo64/testvolume
Do you really want to remove active logical volume testvolume? [y/n]: y
� Logical volume "testvolume" successfully removed

Note that no filesystem is even created here, so it's not mounted or
anything. That volume group has plenty of free extents (vgdisplay
excerpt):

� Alloc PE / Size � � � 52353 / 204.50 GiB
� Free �PE / Size � � � 66794 / 260.91 GiB

This is repeatable every time and waiting arbitrary delays between the
operations makes no difference.�There is no difference if the logical
volume is specified by its device node (/dev/buildturbo64/testsnap).

Under a *non-RAID* Debian Wheezy VM with an otherwise identical
configuration, lvremove works first time, as I'd expect.

Is this a bug, or some form of user error?

Here is the verbose output of the remove steps, if that is helpful:

# lvremove --verbose buildturbo64/testsnap
� � Using logical volume(s) on command line
Do you really want to remove active logical volume testsnap? [y/n]: y
� � Archiving volume group "buildturbo64" metadata (seqno 117).
� � Removing snapshot testsnap
� � Found volume group "buildturbo64"
� � Found volume group "buildturbo64"
� � Loading buildturbo64-testvolume table (254:3)
� � Loading buildturbo64-testsnap table (254:5)
� � Suspending buildturbo64-testvolume (254:3) with device flush
� � Suspending buildturbo64-testsnap (254:5) with device flush
� � Suspending buildturbo64-testvolume-real (254:6) with device flush
� � Suspending buildturbo64-testsnap-cow (254:7) with device flush
� � Found volume group "buildturbo64"
� � Resuming buildturbo64-testsnap-cow (254:7)
� � Resuming buildturbo64-testvolume-real (254:6)
� � Resuming buildturbo64-testsnap (254:5)
� � Removing buildturbo64-testsnap-cow (254:7)
� � Found volume group "buildturbo64"
� � Resuming buildturbo64-testvolume (254:3)
� � Removing buildturbo64-testvolume-real (254:6)
� � Found volume group "buildturbo64"
� LV buildturbo64/testsnap in use: not deactivating
� Unable to deactivate logical volume "testsnap"
# lvremove --verbose buildturbo64/testsnap
� � Using logical volume(s) on command line
Do you really want to remove active logical volume testsnap? [y/n]: y
� � Archiving volume group "buildturbo64" metadata (seqno 118).
� � Found volume group "buildturbo64"
� � Removing buildturbo64-testsnap (254:5)
� � Releasing logical volume "testsnap"
� � Creating volume group backup "/etc/lvm/backup/buildturbo64" (seqno 119).
� Logical volume "testsnap" successfully removed

-- 
Philip Boulain
Developer

philip.boulain@smoothwall.net

Smoothwall Ltd
1 John Charles Way, Leeds, LS12 6QA United Kingdom
Telephone: �USA:�1 800 959 3760��Europe:�+44 (0) 8701 999500
www.smoothwall.net

Smoothwall Limited is registered in England, Company Number: 4298247.
This email and any attachments transmitted with it are confidential to
the intended recipient(s) and may not be communicated to any other
person or published by any means without the permission of Smoothwall
Limited. �Any opinions stated in this message are solely those of the
author.

Re: [linux-lvm] Snapshot removal fails first time under RAID

[Zdenek Kabelac]

Dne 7.3.2012 17:22, Philip Boulain napsal(a):
> We have a Debian Wheezy server using mirrored RAID running kernel
> 3.2.0-1-amd64 and LVM version 2.02.88-2. There seems to be an issue
> where snapshot removal fails due to being "in use" the first time, but
> repeating the operation will succeed:
> 
> # lvcreate --size 128M --name testvolume buildturbo64
>   Logical volume "testvolume" created
> # lvcreate --size 128M --snapshot --name testsnap buildturbo64/testvolume
>   Logical volume "testsnap" created
> # lvremove buildturbo64/testsnap
> Do you really want to remove active logical volume testsnap? [y/n]: y
>   LV buildturbo64/testsnap in use: not deactivating
>   Unable to deactivate logical volume "testsnap"
> # lvremove buildturbo64/testsnap
> Do you really want to remove active logical volume testsnap? [y/n]: y
>   Logical volume "testsnap" successfully removed
> # lvremove buildturbo64/testvolume
> Do you really want to remove active logical volume testvolume? [y/n]: y
>   Logical volume "testvolume" successfully removed
> 
> Note that no filesystem is even created here, so it's not mounted or
> anything. That volume group has plenty of free extents (vgdisplay
> excerpt):
> 
>   Alloc PE / Size       52353 / 204.50 GiB
>   Free  PE / Size       66794 / 260.91 GiB
> 
> This is repeatable every time and waiting arbitrary delays between the
> operations makes no difference. There is no difference if the logical
> volume is specified by its device node (/dev/buildturbo64/testsnap).
> 
> Under a *non-RAID* Debian Wheezy VM with an otherwise identical
> configuration, lvremove works first time, as I'd expect.
> 
> Is this a bug, or some form of user error?
> 

Looks like 'famous' watch rule problem with and udev.

Newer version of lvm are trying to a be bit smarted.
But for now easiest would be to remove  'watch' rule being executed on dm
devices if you need urgent solution.
i.e.:

https://bugzilla.redhat.com/show_bug.cgi?id=753105


Zdenek