From Fedora Project Wiki

< Changes
Revision as of 16:33, 16 July 2020 by Bcotton (talk | contribs) (Add trackers)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)


Introduce Storage Instantiation Daemon

Summary

Introduce Storage Instantiation Daemon (SID) that aims to provide a central event-driven engine to write modules for identifying specific Linux storage devices, their dependencies, collecting information and state tracking while being aware of device groups forming layers and layers forming whole stacks or simply creating custom groups of enumerated devices. SID will provide mechanisms to retrieve and query collected information and a possibility to bind predefined or custom triggers with actions for each group.

Owner

Current status


Detailed Description

Over the years, various storage subsystems have been installing hooks within udev rules and calling out numerous external commands for them to be able to react on events like device presence, removal or a change in general. However, this approach ended up with very complex rules that are hard to maintain and debug if we are considering storage setups where we build layers consisting of several underlying devices (horizontal scope) and where we can stack one layer on top of another (vertical scope), building up diverse storage stacks where we also need to track progression of states either at device level or group level.

SID extends udevd functionality here in a way that it incorporates a notion of device grouping directly in its core which helps with tracking devices in storage subsystems like LVM, multipath, MD... Also, it provides its own database where records are separated into per-device, per-module, global or udev namespace. The udev namespace keeps per-device records that are imported and/or exported to/from udev environment and this is used as compatible communication channel with udevd. The records can be marked with restriction flags that aid record separation and it prevents other modules to read, write or create a record with the same key, hence making sure that only a single module can create the records with certain keys (reserving a key).

Currently, SID project provides a companion command called 'usid' which is used for communication between udev and SID itself. After calling the usid command in a udev rule, device processing is transferred to SID and SID strictly separates the processing into discrete phases (device identificaton, pre-scan, device scan, post-scan). Within these phases, it is possible to decide whether the next phase is executed and it is possible to schedule delayed actions or set records in the database that can fire triggers with associated actions or records which are then exported to udev environment (mainly for backwards compatibility and for other udev rules to have a chance to react). The scheduled actions and triggers are executed out of udev context and hence not delaying the udev processing itself and improving issues with udev timeouts where unnecessary work is done.

A module writer can hook into the processing phases and use SID's API to access the database as well as set the triggers with actions or schedule separate actions and mark devices as ready or not for use in next layers. The database can be used within any phase to retrieve and store key-value records (where value could be any binary value in general) and the records can be marked as transient (only available during processing phases for current event) or persistent so they can be accessed while processing subsequent events.

Feedback

Benefit to Fedora

The main benefit is all about centralizing the solution to solve issues that storage subsystem maintainers have been hitting with udev, that is:

  • providing a central infrastructure for storage event processing, currently targeted at udev events
  • improving the way storage events and their sequences are recognized and for which complex udev rules were applied before
  • single notion of device readiness shared among various storage subsystems (single API to set the state instead of setting various variables by different subsystems)
  • providing more enhanced possibilities to store and retrieve storage-device-related records when compared to udev database
  • direct support for generic device grouping (matching subsystem-related groups like LVM, multipath, MD... or creating arbitrary groups of devices)
  • centralized solution for scheduling triggers with associated actions defined on groups of storage devices
  • adding a centralized solution for delayed actions on storage devices and groups of devices (avoiding unnecessary work done within udev context and hence avoiding frequent udev timeouts when processing events for such devices)

Scope

  • Proposal owners:
    • complete SID's infrastructure to fully support stabilized API for other developers to start writing modules for SID;
    • document all of current SID's functionality, including the module API and explain the difference (extension) to udev, write and complete man pages;
    • provide udev rules responsible for communication with SID and possibly importing records which were marked for export to udev in SID.
  • Other developers:
    • first version will make use of a module to handle device-mapper-multipath devices (device-mapper-multipath package)
    • consult in more detail possibility of adding an LVM module even for this release (if not feasible at this moment, then postpone development of this module to next release)
  • Release engineering: #9568 (a check of an impact with Release Engineering is needed)
  • Policies and guidelines: no changes needed at this moment
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

We are introducing SID in this release and it will be disabled by default so an upgrade has no impact here - all existing udev rules for various storage subsystems will still be installed as previously. Subsystems for which a module will be already available in this release will contain a switch in their udev rules to either use the old udev rules (if SID is not active) or skip the rules appropriately (if SID is active and related processing is handled within the SID module instead).

How To Test

  • Basic testing involves (considering we have at least multipath and/or LVM module present as well):
    • installing new 'sid' package
    • installing device-mapper-multipath and/or lvm module (presumably named device-mapper-multipath-sid-module and lvm2-sid-module)
    • creating a device stack including device-mapper-multipath and/or LVM volumes
    • booting with 'sid.enabled=1' kernel command line
    • checking device-mapper-multipath and/or LVM volumes are correctly activated
  • More thorough testing:
    • (TBD)

User Experience

Regular users shouldn't notice any change. SID is providing a system-level infrastructure for convenient handling of storage-device-related events through modules provided by other developers.

Dependencies

  • a module to handle device-mapper-multipath is in cooperative development with this change, the module will land in device-mapper-multipath package (or its subpackage)
  • the same applies for the LVM module (but that may be postponed as described earlier)

Contingency Plan

If SID is not complete in time, there's no need to execute any special backup plans. The distribution still contains all the original udev rules to handle events for storage devices. If device-mapper-multipath and/or LVM provides the SID modules, these won't be built and distributed.

SID is not enabled by default so to start using it, one needs to enable it explicitly. If enabling SID causes problems, it can be disabled. For this purpose, there will be a kernel command line to enable/disable SID so we avoid possible issues even at early boot sequence if the device handled by SID is on critical path within boot sequence.

Documentation

Release Notes

Retrieved from "https://fedoraproject.org/w/index.php?title=Changes/SID&oldid=582457"