[RFC PATCH 0/7] device mapper udev rules rework

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



All,

here is a draft for a rewrite of the device mapper udev rules, as follow up
to the previous thread "About DM_UDEV_DISABLE_OTHER_RULES_FLAG and
DM_NOSCAN" [1]. While I have taken care to minimize the impact on
other udev rule sets, some changes to both the multipath-tools and
systemd rules will be necessary. Patches for these are in preparation,
but I'd like to reach consensus on the dm part first.

As discussed in [1], the idea is to use just one udev property as "API" for
later rules to determine whether the device at hand can be probed or
otherwise accessed. This API remains DM_UDEV_DISABLE_OTHER_RULES_FLAG,
because it is widely used by other rule sets. This means that the flag of
the same name that is set in the DM_COOKIE needs to be saved and restored
via a different property. For this property, I've chosen the name
DM_COOKIE_DISABLE_OTHER_RULES_FLAG, which is hopefully awkward enough that
authors of non-dm rules won't consider using it.

DM_UDEV_DISABLE_OTHER_RULES_FLAG is a logical "OR" of various conditions
that should prevent other rules from accessing a device. This includes the
cookie flag, the "suspended" flag, and the "noscan" flag
(DM_SUBSYSTEM_UDEV_FLAG0=1). dm-multipath has more such conditions.

Because DM_SUSPENDED and DM_NOSCAN are now purely internal and don't need to
be restored from the udev db, they are renamed to .DM_SUSPENDED and
.DM_NOSCAN, respectively.

For follow-up rules, the semantics of DM_UDEV_DISABLE_OTHER_RULES_FLAG=1
is "don't probe, don't attempt IO, and keep existing device properties
(if any) until subsequent uevents are received". It doesn't mean the
device should be completely ignored, and it doesn't mean that the block
layer stack on top of the device should be destroyed. Contrary to what
we discussed in [1], I didn't try to come up with flags carrying these
other meanings. I the LVM layer doesn't have the necessary information
for doing this. The only flag with "destroy" semantics I am aware of
is SYSTEMD_READY="0", and it's up to systemd to deal with that.

The first two patches are minor fixes that I came up with while working
on the rules.

[1] https://lore.kernel.org/linux-lvm/9d50edb0-baa4-4a01-a2f0-136dfdb79937@xxxxxxxxxx/T/#t

Martin Wilck (7):
  13-dm-disk.rules: import ID_FS_TYPE
  10-dm.rules: don't deactivate devices for DISK_RO=1
  10-dm-rules: don't restore DM_UDEV_DISABLE_OTHER_RULES_FLAG from db
  11-dm-lvm.rules: don't restore DM_UDEV_DISABLE_OTHER_RULES_FLAG from
    db
  dm udev rules: don't export and save DM_SUSPENDED
  dm udev rules: don't export and save DM_NOSCAN
  10-dm.rules: bump DM_UDEV_RULES_VSN to 3

 udev/10-dm.rules.in          | 32 +++++++++++++++++++++-----------
 udev/11-dm-lvm.rules.in      | 13 +++++--------
 udev/12-dm-permissions.rules |  2 +-
 udev/13-dm-disk.rules.in     |  9 +++++----
 4 files changed, 32 insertions(+), 24 deletions(-)

-- 
2.43.2





[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux