[linux-lvm] Identifying useable block devices

Peter Rajnoha prajnoha at redhat.com
Fri Jan 24 13:24:56 UTC 2014

On 01/23/2014 01:35 PM, Marius Vollmer wrote:
> Peter Rajnoha <prajnoha at redhat.com> writes:
>> On 01/22/2014 10:23 AM, Marius Vollmer wrote:
>>> 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?
>> No, we don't have this restriction generally
> Ok.
>>> 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.
>> Well, udisks should always check the DM_UDEV_DISABLE_OTHER_RULES_FLAG
>> and if it's set, skip its processing. It already has:
>> # honor the flag that device-mapper sets if the device should be ignored
>> ..in 80-udisks.rules. So it should be already following this.
> That's from UDisks 1, I am concerned with UDisks2, which is a quite
> different beast, I think.  Sorry for not making this clear.
> The problem with UDisks2, as I see it, is that it ignores a "change" or
> "add" event that has DM_UDEV_DISABLE_OTHER_RULES_FLAG set, while I think
> it should treat it as a "remove" event.
> I have proposed this patch:
>     https://bugs.freedesktop.org/attachment.cgi?id=92577&action=edit

Well, I don't quite agree with this statement from the patch:
 "We treat the uevent as "remove" if the device-mapper layer
  requests that other rules ignore this uevent".

The flag (DM_UDEV_DISABLE_OTHER_RULES_FLAG) is here to direct
udev processing to skip any scans - it's not actually saying
everyone else should remove this device now. It's just saying
"don't access/touch it" when this flag is set. If there was a
situation where we really need to remove (deactivate) the device,
we'd do that in lvm2 directly within processing of the device.

 "It's somewhat nasty to do this but it avoids all kinds of
  race-conditions caused by the design of device-mapper
  (such as temporary-cryptsetup nodes and cleartext devices
  without ID_FS properties properly set)."

The only reason we have these flags is that there's no way in
udev to declare the device as being private. The ID_FS_*
properties are the result of the blkid scan. And that's
exactly what we need to avoid! (...one of the reasons is
that such a private device could contain garbage since it's
not yet initialized fully). So it's actually the other way

>> Hmm, could you please send the whole log.
> Sure, attached.

Thanks! Well, sorry for that, I've finally noticed the thing,
that was another bug, unfortunately. Should be solved now with
this git head in lvm2 upstream:

Thing is that the pool volume *should always* be marked
as private which also means DM_UDEV_DISABLE_OTHER_RULES_FLAG
is set.

More information about the linux-lvm mailing list