Bug 73731 - UDisks2 doesn't handle LVM2 thin volumes well.
Summary: UDisks2 doesn't handle LVM2 thin volumes well.
Status: NEW
Alias: None
Product: udisks
Classification: Unclassified
Component: detection (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: David Zeuthen (not reading bugmail)
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-01-17 09:19 UTC by Marius Vollmer
Modified: 2014-12-08 14:08 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Don't look at DM_UDEV_DISABLE_OTHER_RULES_FLAG. (3.85 KB, text/plain)
2014-01-17 09:19 UTC, Marius Vollmer
Details
Treat certain device mapper udev events as "remove"... (2.78 KB, patch)
2014-01-22 11:35 UTC, Marius Vollmer
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Marius Vollmer 2014-01-17 09:19:02 UTC
Created attachment 92270 [details]
Don't look at DM_UDEV_DISABLE_OTHER_RULES_FLAG.

Fedora 20.

When a pool is created while UDisks2 is running, it creates a D-Bus object for the block device of that pool.  When UDisks2 is then restarted, this object disappears.

UDisks2 never creates D-Bus objects for block devices of thin volumes.

The following commands can be used to reproduce this:

  # dd if=/dev/zero of=/disk.img bs=1M count=100
  # L=$(losetup -f --show /disk.img)
  # vgcreate TEST $L

  Create a thin pool.
  # lvcreate TEST --thinpool pool -L 80

  A UDisks2 block device for it will appear
  # udisksctl dump | grep block_devices/dm
  /org/freedesktop/UDisks2/block_devices/dm_2d0:

  Restarting UDisks2 will make it disappear
  # systemctl restart udisks2
  # udisksctl dump | grep block_devices/dm
  <empty>

  Create a thin volume.
  # lvcreate -T TEST/pool -n thin -V 100

  No UDisks2 block device for it will appear
  # udisksctl dump | grep block_devices/dm
  <empty>
  # ls -l /dev/TEST/thin
  lrwxrwxrwx 1 root root 7 Jan 17 11:15 /dev/TEST/thin -> ../dm-4

The attached patch tries to fix this by stopping to look at DM_UDEV_DISABLE_OTHER_RULES_FLAG, which doesn't seem to be a reliable thing to do in any case.

This will cause extra block devices to show up as D-Bus objects, and we set UDISKS_IGNORE for them via a udev rule.  (We could try to push the lvm2-is-internal-lv script to LVM2 itself.)
Comment 1 Marius Vollmer 2014-01-17 14:25:46 UTC
A better alternative to this patch might be to wait for LVM2 to document the DM_UDEV_DISABLE_OTHER_RULES_FLAG and make it work for thin volumes.

https://www.redhat.com/archives/linux-lvm/2014-January/msg00019.html

However, UDisks2 would still need to handle changes in the DM_UDEV_DISABLE_OTHER_RULES_FLAG.  A "add" or "change" event with that flag set should not be totally ignored.  Maybe it is enough to treat it as equivalent to a "remove".
Comment 2 David Zeuthen (not reading bugmail) 2014-01-20 20:27:42 UTC
I think this is a bug in device-mapper and I think the fix needs to happen there - workarounds like you suggest might work for a while and then break horribly later on.

Ideally we would drop support for the DM_UDEV_DISABLE_OTHER_RULES flag and device-mapper apps would cope with other apps (udev, udisks, whatever) temporarily opening the created device nodes when they are announced to user space. Or better, device-mapper wouldn't create user-space visible device nodes with the expectation that they are the only user.

Since you are at Red Hat and have easier access to the device-mapper team, is it possible you can talk to them about it?
Comment 3 Marius Vollmer 2014-01-22 09:38:42 UTC
(In reply to comment #2)
> I think this is a bug in device-mapper and I think the fix needs to happen
> there

Yes, half of this is fixed in LVM2:

https://git.fedorahosted.org/cgit/lvm2.git/commit/?id=91b26b63b408b7d7b4f79f0754d190783874e4cc

I'll try to figure out what to do about the other half (the flag appearing in a "change" event and not just disappearing):

https://www.redhat.com/archives/linux-lvm/2014-January/msg00035.html

I now think this should also be fixed (and documented) by LVM2, but let's see.

> Since you are at Red Hat and have easier access to the device-mapper team,
> is it possible you can talk to them about it?

The discussion on linux-lvm with Peter seems to be flowing well enough, I'd say.
Comment 4 Marius Vollmer 2014-01-22 11:35:25 UTC
Created attachment 92577 [details] [review]
Treat certain device mapper udev events as "remove"...

(In reply to comment #3)
> I'll try to figure out what to do about the other half (the flag appearing
> in a "change" event and not just disappearing):
> 
> https://www.redhat.com/archives/linux-lvm/2014-January/msg00035.html
> 
> I now think this should also be fixed (and documented) by LVM2, but let's
> see.

In case you you want UDisks2 to be a bit more robust against device mapper inanities, the attached patch is what I have in mind.  I haven't tested it very much.
Comment 5 Marius Vollmer 2014-01-23 17:08:30 UTC
(In reply to comment #4)
> Created attachment 92577 [details] [review] [review]
> Treat certain device mapper udev events as "remove"...
> 
> (In reply to comment #3)
> > I'll try to figure out what to do about the other half (the flag appearing
> > in a "change" event and not just disappearing):
> > 
> > https://www.redhat.com/archives/linux-lvm/2014-January/msg00035.html
> > 
> > I now think this should also be fixed (and documented) by LVM2, but let's
> > see.
> 
> In case you you want UDisks2 to be a bit more robust against device mapper
> inanities, the attached patch is what I have in mind.  I haven't tested it
> very much.

Looks like the flag can come and go arbitrarily, so I think the patch is appropriate. (Unless it's buggy , of course.)

https://www.redhat.com/archives/linux-lvm/2014-January/msg00036.html


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.