Can't remove snapshot at first

Hi.

I noticed, that rather often, I'm unable to remove an unused snapshot volume at first command execution. See this:

--($ ~)-- sudo /sbin/lvremove /dev/Sys/Home-Backup_Snapshot
Can't remove open logical volume "Home-Backup_Snapshot"

--($ ~)-- sudo /sbin/lvremove /dev/Sys/Home-Backup_Snapshot
Do you really want to remove active logical volume Home-Backup_Snapshot? [y/n]:

Between those two commands, I did not do anything at all! I ran the commands directly after each other in like 5 seconds or so.

Why's that so?

--($ ~)-- sudo /sbin/lvm version
LVM version: 2.02.70(2) (2010-07-06)
Library version: 1.02.52 (2010-07-06)
Driver version: 4.17.0

--($ ~)-- uname -a
Linux winnb000546 2.6.35-ARCH #1 SMP PREEMPT Sat Aug 21 07:23:08 UTC 2010 i686 Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz GenuineIntel GNU/Linux

This is a Arch Linux system.

Thanks,
Alexander

Do you have "udisks" installed? There's a problem we track already and this seems to be the same:

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

Peter

Hi.

2010/8/25 Peter Rajnoha <[email protected]>

TBH, I don't know what udisks is, but, yes, it's installed.

--($ /.backup/lib)-- pacman -Q udisks
udisks 1.0.1-5

And it's running as well...

root 9604 0.0 0.1 13708 3088 ? Sl 07:47 0:10
/usr/lib/udisks/udisks-daemon

I removed that line from the udev rule, and now the problem seems to be gone.

Alexander
--
↯    Lifestream (Twitter, Blog, …) ↣ http://alexs77.soup.io/     ↯ ↯ Chat (Jabber/Google Talk) ↣ [email protected] , AIM: alexws77  ↯

I t is possible that udev run some async scan in reaction to even (during snap manipulation).

Distro maintainers should probably update lvm udev rules (and possibly udisks rules etc) to work relieably.

Upstream lvm2 with combination of recent udev and udisks package should have this fixed (hopefully).

Milan

Well, not completely in this exact case. It's hard to cover this situation with "nowatch"/dm udev flags here because someone could change the contents of the volume and so the snapshot volume and original volume can differ.

Anyone scanning for those changes in udev rules could miss the change of a symlink name based on some changed attribute or some other call that notifies about changes in general.

We can rule out the mirror's _mimage, snapshot's -cow/-real etc. scanning, but the top-level snapshot - unfortunately not.

So for now, it would be better to just try to comment out that watch rule in udisks udev rules so we can see that is the case.

If yes, we can make our argument that this really causes problems even stronger and try to persuade people who use the watch rule to be inclined to some other alternative solution that is less problematic to support.

Peter

Hi.

2010/8/25 Peter Rajnoha <[email protected]>:

Sorry, I guess I was "a bit" too hasty, when I said that removing the line helped... I'm still getting the error in my OP.

Alexander
--
↯    Lifestream (Twitter, Blog, …) ↣ http://alexs77.soup.io/     ↯ ↯ Chat (Jabber/Google Talk) ↣ [email protected] , AIM: alexws77  ↯

Hello!

2010/8/25 Milan Broz <[email protected]>:

Guess so.

Hm. I have udisks 1.0.1 installed.
http://cgit.freedesktop.org/DeviceKit/DeviceKit-disks/
lists 1.0.1 as the most recent, so what should Arch Linux do in this case?

Same for udev - http://www.kernel.org/pub/linux/utils/kernel/hotplug/?C=M;O=D
lists udev-161 as the latest and I do have udev-161 installed.

But LVM2 is indeed out of date - I've got 2.02.70. Would've .71 or .73 have fixed this?

BTW: I'm on kernel 2.6.35.3-1. Well, I guess that should be 2.6.35.3, but should the
uname -a output show 2.6.35.3?

Alexander
--
↯    Lifestream (Twitter, Blog, …) ↣ http://alexs77.soup.io/     ↯ ↯ Chat (Jabber/Google Talk) ↣ [email protected] , AIM: alexws77  ↯