[linux-lvm] Identifying useable block devices

[Marius Vollmer]

Peter Rajnoha <prajnoha at redhat.com> writes:

>> Thing here is that when LVs are created then at first they have this flag
>> set until proper initialization is finished - [...]

Is it guaranteed (modulo bugs) that the DM_UDEV_DISABLE_*_RULES flags
are only ever removed from a node, and are never added to it over it's
lifetime between add/remove events?

This isn't true right now, and UDisks fails to handle it correctly when
a flag is added in a "change" event.  I am asking to figure out where
the fix should go.

For example, this is what happens when creating a pool for thinly
provisioned volumes:

    UDEV  [2081.714175] add      /devices/virtual/block/dm-1 (block)
    [...]
    DM_UDEV_DISABLE_DISK_RULES_FLAG=1
    DM_UDEV_DISABLE_OTHER_RULES_FLAG=1
    DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1
    [...]

    UDEV  [2081.771737] change   /devices/virtual/block/dm-1 (block)
    [...]
    DM_UDEV_DISABLE_LIBRARY_FALLBACK_FLAG=1
    [...]

    UDEV  [2081.779997] change   /devices/virtual/block/dm-1 (block)
    [...]
    DM_UDEV_DISABLE_LIBRARY_FALLBACK_FLAG=1
    [...]

    UDEV  [2081.943224] change   /devices/virtual/block/dm-1 (block)
    [...]
    DM_UDEV_DISABLE_DISK_RULES_FLAG=1
    DM_UDEV_DISABLE_LIBRARY_FALLBACK_FLAG=1
    DM_UDEV_DISABLE_OTHER_RULES_FLAG=1
    DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1
    [...]

I.e., the flags are set, then are removed, then set again.  UDisks
ignores the change event with the flags set, and gets into an
inconsistent state.

(With my limited understanding, I would say that LVM2 should make the
guarantee and fix the above scenario.)

> ...the flag would be gone if you opened the LV for read-write and then
> close it - you don't even need to write anything to the LV, just open
> and close - this would fire an event that would have dropped the flag.

Thanks, that sounds like a good workaround until your fix is available
where we need it.