| Summary: | UDisks2 doesn't handle LVM2 thin volumes well. | ||
|---|---|---|---|
| Product: | udisks | Reporter: | Marius Vollmer <marius.vollmer> |
| Component: | detection | Assignee: | David Zeuthen (not reading bugmail) <zeuthen> |
| Status: | NEW --- | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | bugs |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
Don't look at DM_UDEV_DISABLE_OTHER_RULES_FLAG.
Treat certain device mapper udev events as "remove"... |
||
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". 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? (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. 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. (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.
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.)