From: Zdenek Kabelac <zkabelac@redhat.com>
To: LVM general discussion and development <linux-lvm@redhat.com>
Cc: Philip Boulain <philip.boulain@smoothwall.net>
Subject: Re: [linux-lvm] Snapshot removal fails first time under RAID
Date: Fri, 09 Mar 2012 14:42:50 +0100 [thread overview]
Message-ID: <4F5A08DA.80402@redhat.com> (raw)
In-Reply-To: <CAKxJzGeWwVGOOH8VX08Rk_icG3uBEAvbPjRMSw=41Vt9gY_L1g@mail.gmail.com>
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
prev parent reply other threads:[~2012-03-09 13:42 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-07 16:22 [linux-lvm] Snapshot removal fails first time under RAID Philip Boulain
2012-03-09 13:42 ` Zdenek Kabelac [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F5A08DA.80402@redhat.com \
--to=zkabelac@redhat.com \
--cc=linux-lvm@redhat.com \
--cc=philip.boulain@smoothwall.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.