== 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 ==
* Name: [[User:prajnoha | Peter Rajnoha]]
* Email:

== 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

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.

== 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

* 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]
* 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

== 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

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

== Documentation ==
* documentation (will be completed):*
upstream repository:

Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
devel mailing list --
To unsubscribe send an email to
Fedora Code of Conduct:
List Guidelines:
List Archives:

Reply via email to