dk-disks shows internal LVs and Log of mirrored LVM LVs

Created an attachment (id=30520)
output of udevadm info --export-db

Created an attachment (id=30521)
output of devkit-disks --dump

Created an attachment (id=30522)
output of lvmdump

This is in fact just a corollary of dk-disks handling lvm/dm/md devices itself in the rules, instead of having dmsetup/mdadm etc. ship their own rules. These rules are currently being introduced upstream, but didn't trickle through all the distros yet.

This was recently discussed at length in this Debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=545032#56

Upstream lvm2 fixed that a while ago in its udev rules:
http://sourceware.org/ml/lvm2-cvs/2009-08/msg00018.html

+ENV{DM_LV_NAME}=="?*_mlog", GOTO="lvm_end"
+ENV{DM_LV_NAME}=="?*_mimage_[0-9]*", GOTO="lvm_end"

(In reply to comment #4)
> This is in fact just a corollary of dk-disks handling lvm/dm/md devices itself
> in the rules, instead of having dmsetup/mdadm etc. ship their own rules. These
> rules are currently being introduced upstream, but didn't trickle through all
> the distros yet.
>
> This was recently discussed at length in this Debian bug:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=545032#56
>
> Upstream lvm2 fixed that a while ago in its udev rules:
> http://sourceware.org/ml/lvm2-cvs/2009-08/msg00018.html

Just FYI, the Fedora lvm2 packages omit these udev rules. It conflicted with dracut or anaconda or something so they decided to pull it. To add insult to injury, keep in mind that the Fedora lvm2 package maintainers practically are the upstream lvm2 maintainers. So they're not eating their own dog food. To say that I'm happy with the lvm2 maintainers would be a lie.

So I guess we have to ship our own crap in DKD for a while more.

>
> +ENV{DM_LV_NAME}=="?*_mlog", GOTO="lvm_end"
> +ENV{DM_LV_NAME}=="?*_mimage_[0-9]*", GOTO="lvm_end"
>

(In reply to comment #0)
> Created an attachment (id=30519) [details]
> output of ls -lR /sys
>
> I have a LVM setup, with one LV in mirrored mode (RAID1) spread over 2 PVs. For
> such a setup, 3 more DM devices are generated: VG-LV_mimage_0, VG-LV_mimage_1
> und VG-LV_mlog. These devices do *not* respresent real LVs, and shouldn't be
> included in dk-disks.

Maybe if these three devices don't represent anything useful, then LVM2 shouldn't expose them as block devices?

But, yes, we need to add proper LVM2 support to DeviceKit-disks / Palimpsest in the same way that we have proper MD (Linux Software RAID) support. This includes untangling the mess that the LVM2 guys like to add an additional three block devices to confuse users. Anyway, that's bug 24672 and I guess we can close either as a duplicate of the other. This bug contains more information so I'm tempted to close bug 24672 as a dupe of this bug.

>
> $ sudo lvs
> LV VG Attr LSize Origin Snap% Move Log
> home ubuntu mwi-ao 465.76G home_mlog
> root ubuntu -wi-ao 10.00G
> swap ubuntu -wi-ao 4.00G
>
> $ sudo lvs -a
> LV VG Attr LSize Origin Snap% Move Log
> home ubuntu mwi-ao 465.76G home_mlog
> [home_mimage_0] ubuntu iwi-ao 465.76G
> [home_mimage_1] ubuntu iwi-ao 465.76G
> [home_mlog] ubuntu lwi-ao 4.00M
> root ubuntu -wi-ao 10.00G
> swap ubuntu -wi-ao 4.00G
>
> To reproduce, create an LVM setup with at least 2 PVs, and change a LV to
> mirrored mode with "sudo lvconvert -m 1 VG/LV".
>

Going to use this bug for implementing proper LVM2 support. Adjusting title as needed.

*** Bug 24672 has been marked as a duplicate of this bug. ***

> Upstream lvm2 fixed that a while ago in its udev rules:
> http://sourceware.org/ml/lvm2-cvs/2009-08/msg00018.html

> +ENV{DM_LV_NAME}=="?*_mlog", GOTO="lvm_end"
> +ENV{DM_LV_NAME}=="?*_mimage_[0-9]*", GOTO="lvm_end"

FYI, I just added some basic LVM test cases (single LV/no RAID, and single LV/RAID-1) to the test suite (see bug 24446). This checks the "presentation hide" flag as well, so without the patch above (or the equivalent that was applied in Ubuntu), it fails:

======================================================================
FAIL: LVM: Single LV, RAID-1
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/martin/dk-disks-test.py", line 1032, in test_single_lv_raid
    o != real_lv_obj)
AssertionError: dbus.Boolean(False, variant_level=1) != True

(that's the DevicePresentationHide property).

So regardless how distros ship their udev rules right now, they can use this to test that they have a correct setup which probes the LVs and hides the shadow image LVs.

Ah, please ignore my previous comment. I just noticed that PRESENTATION_HIDE does not hide a device from palimpsest. OTOH the devices were never actually shown in GNOME since that checks for usage "filesystem". So I changed the test suite to just ensure that mirror images have an emty usage.

That said, _should_ palimpsest show devices which have "presentation hide"?

For udisks 2.0 we don't do LVM stuff any more and we even changed the default to off in the udisks1 branch and the udisks 1.0.4 release for these reasons

 http://cgit.freedesktop.org/udisks/commit/?h=udisks1&id=99de237eed6a026597e9b045527631c42ab86968

Closing as WONTFIX as there are no immediate plans to add this.