You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The device-mapper udev rules define several environment variables that can be used to control udev rule processing and device visibility for DM devices. These are exposed in DmUdevFlags and are used internally to control udev processing of devices managed with devicemapper-rs:
pubstructDmUdevFlags:u32{/// Disables basic device-mapper udev rules that create symlinks in /dev/<DM_DIR>/// directory.
const DM_UDEV_DISABLE_DM_RULES_FLAG = dmi::DM_UDEV_DISABLE_DM_RULES_FLAG;/// Disable subsystem udev rules, but allow general DM udev rules to run.constDM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG = dmi::DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG;/// Disable dm udev rules which create symlinks in /dev/disk/* directory.constDM_UDEV_DISABLE_DISK_RULES_FLAG = dmi::DM_UDEV_DISABLE_DISK_RULES_FLAG;/// Disable all rules that are not general dm nor subsystem related.constDM_UDEV_DISABLE_OTHER_RULES_FLAG = dmi::DM_UDEV_DISABLE_OTHER_RULES_FLAG;/// Instruct udev rules to give lower priority to the device.constDM_UDEV_LOW_PRIORITY_FLAG = dmi::DM_UDEV_LOW_PRIORITY_FLAG;/// Disable libdevmapper's node management.constDM_UDEV_DISABLE_LIBRARY_FALLBACK = dmi::DM_UDEV_DISABLE_LIBRARY_FALLBACK;/// Automatically appended to all IOCTL calls issues by libdevmapper for generating/// udev uevents.constDM_UDEV_PRIMARY_SOURCE_FLAG = dmi::DM_UDEV_PRIMARY_SOURCE_FLAG;}
Historically ThinDev devices are the only devices for which DM_UDEV_PRIMARY_SOURCE_FLAG is set. This is a design decision that supports Stratis' needs: only the leaf thin devices are exposed. Other device types (CacheDev, LinearDev, and ThinPoolDev) did not set this flag and hence were "hidden" devices.
The changes to add Udev synchronization inadvertently changed the default for all device types, since DM_UDEV_PRIMARY_SOURCE_FLAG is now set automatically for ioctl operations that generate uevents. This is a user visible change in behaviour and causes problems for other subsystems, for e.g. Udisks:
Description of problem:
the latest update on fedora of stratisd 3.5.1-1.fc37 -> 3.5.2-1.fc37 broke cockpit-storaged tests.
It looks like now udisks lists as block devices some stratis private objects.
The immediate issue is addressed in #845 by explicitly setting three DmUdevFlags values for these device types:
This restores the historical behaviour of devicemapper-rs 0.32.3 and earlier as expected by Stratis.
For a general purpose library this behaviour should be optional and under the control of users of the crate. This requires breaking changes to the library API to allow callers to specify create_options that govern the visibility of the objects being managed as discussed in stratis-storage/project#389
The text was updated successfully, but these errors were encountered:
This is relatively straightforward: adding the create_options as an Option to the existing new() and setup() methods for each device type gives users of the crate four options to control visibility and other properties of the created devices:
create_options devicemapper-rs device behavior
+----------------------------+------------------------------------------------+
| None | Accept historical library defaults. |
+----------------------------+------------------------------------------------+
| Some(DmOptions::default()) | Library defaults for visible devices. |
+----------------------------+------------------------------------------------+
| Some(DmOptions::private()) | Library defaults for private (hidden) devices. |
+----------------------------+------------------------------------------------+
| Some(custom_options) | Caller has complete control of options/flags. |
+----------------------------+------------------------------------------------+
The changes in Stratis to make use of this are also smaller than I'd anticipated:
I.e. if users pass None for the create_options then the behaviour is consistent with devicemapper-rs versions before 0.32.3. We should probably be explicit about this in Stratis and use DmOptions::default() and DmOptions::private() for visible and hidden devices respectively.
The device-mapper udev rules define several environment variables that can be used to control udev rule processing and device visibility for DM devices. These are exposed in
DmUdevFlags
and are used internally to control udev processing of devices managed with devicemapper-rs:Historically
ThinDev
devices are the only devices for whichDM_UDEV_PRIMARY_SOURCE_FLAG
is set. This is a design decision that supports Stratis' needs: only the leaf thin devices are exposed. Other device types (CacheDev
,LinearDev
, andThinPoolDev
) did not set this flag and hence were "hidden" devices.The changes to add Udev synchronization inadvertently changed the default for all device types, since
DM_UDEV_PRIMARY_SOURCE_FLAG
is now set automatically for ioctl operations that generate uevents. This is a user visible change in behaviour and causes problems for other subsystems, for e.g. Udisks:The immediate issue is addressed in #845 by explicitly setting three
DmUdevFlags
values for these device types:This restores the historical behaviour of devicemapper-rs 0.32.3 and earlier as expected by Stratis.
For a general purpose library this behaviour should be optional and under the control of users of the crate. This requires breaking changes to the library API to allow callers to specify
create_options
that govern the visibility of the objects being managed as discussed in stratis-storage/project#389The text was updated successfully, but these errors were encountered: