2:18 p.m.
https://fedoraproject.org/wiki/Changes/SID
== 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: prajnoha(a)redhat.com
== 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.
== 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: [https://pagure.io/releng/issue/9568 #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
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 ==
* documentation (will be completed): https://sid-project.github.io/*
upstream repository: https://github.com/sid-project/sid-mvp
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
2:35 p.m.
New subject: Introduce Storage Instantiation Daemon - Fedora 33 System-Wide
Change proposal
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On Tue, 2020-06-30 at 15:18 -0400, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/SID
== 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: prajnoha(a)redhat.com
== 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.
== 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)
Is this purely about adding some package into the repositories and just
to raise awarness that such tool exist?
== 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: [https://pagure.io/releng/issue/9568 #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
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 ==
* documentation (will be completed): https://sid-project.github.io/*
upstream repository: https://github.com/sid-project/sid-mvp
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
- --
Igor Raits <ignatenkobrain(a)fedoraproject.org>
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl77lBMACgkQEV1auJxc
Hh7VAQ/7B+6trAXJOJSusP7XzXfcjtyfk4rxriiyccfHsqEriHnVhbpipWJ2TrVe
YnOdvDK0+iU+PNgyZueXV4OBZWaQLw76f+HC+0IbWlYuejIWKmEu/DRxnQS0Iz+6
rjjvPI5Iqggvk9djezoF6Uix9f0I4CXisnZY3Rag3DvzD9Tx420A0iBRij3UeD1t
w7KBcsrl8G4g5y+0RKI3voc5yuZj1EUBAa75dAE63BGRJTSmkP8zHA2JQM9WAhRR
1hKWW48cNag3USmveu/wIRp9SIpGPVo4xwiM18bga3jZuavIlmFZF52jb3TFASL9
seqD1MMO0gCj/12yeEHUzwSAtqMH204aqeBx5uymoY9JVclgnXds8nD72oZpr4YQ
mF7FpOv3gxgfrP2l47mH3GeLtrbVxt/TA9DaDM6qVi6xZRRf0Pzi0tSS5mt/kO/n
jLGeLNW9TrGtMPgWjhljNBIXmbiIzZhrfoUQd+ChfUM3E49eqz7D7+fgT3XQpXoB
nGTUq/HCOpDKUZNX3hVPpTELX7zxA5oOiNcNm7gGkR7scgDmqhKQV8aWMPbJLbu5
qORm0n0ERi9BBD3/OtQee2WW61g6W0iLHMs2QtkFdYUu9jrdUtA2nrPC3Fsz1J8z
4yp3aLtPksX9E+Lc/9JfqB6WxLqu9Rx6jpD3+Og8vbU+e1nddzo=
=m6Nr
-----END PGP SIGNATURE-----
6:59 a.m.
New subject: Introduce Storage Instantiation Daemon - Fedora 33 System-Wide
Change proposal
On 6/30/20 9:35 PM, Igor Raits wrote:
On Tue, 2020-06-30 at 15:18 -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/SID
> == 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: prajnoha(a)redhat.com
> == 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.
> == 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)
Is this purely about adding some package into the repositories and just
to raise awarness that such tool exist?
It's introducing a new mechanism we could use to better handle events for
storage devices - so yes, also raising awareness. At this moment, adding a new
package with the daemon and accompanying tools and the functionality disabled
by default. Then filling it up with modules, then thinking about making it
enabled by default, getting there step-by-step...
--
Peter
7:03 a.m.
New subject: Introduce Storage Instantiation Daemon - Fedora 33 System-Wide
Change proposal
On Wed, Jul 1, 2020 at 8:00 AM Peter Rajnoha <prajnoha(a)redhat.com> wrote:
On 6/30/20 9:35 PM, Igor Raits wrote:
> On Tue, 2020-06-30 at 15:18 -0400, Ben Cotton wrote:
>> https://fedoraproject.org/wiki/Changes/SID
>
>> == 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: prajnoha(a)redhat.com
>
>> == 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.
>
>> == 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)
>
> Is this purely about adding some package into the repositories and just
> to raise awarness that such tool exist?
>
It's introducing a new mechanism we could use to better handle events for
storage devices - so yes, also raising awareness. At this moment, adding a new
package with the daemon and accompanying tools and the functionality disabled
by default. Then filling it up with modules, then thinking about making it
enabled by default, getting there step-by-step...
I'll be honest, I don't get why this exists. Most folks expect this to
be an aspect of UDisks, so why isn't it?
--
真実はいつも一つ！/ Always, there's only one truth!
7:24 a.m.
New subject: Introduce Storage Instantiation Daemon - Fedora 33 System-Wide
Change proposal
On Wed, Jul 01, 2020 at 08:03:11AM -0400, Neal Gompa wrote:
On Wed, Jul 1, 2020 at 8:00 AM Peter Rajnoha
<prajnoha(a)redhat.com> wrote:
>
> On 6/30/20 9:35 PM, Igor Raits wrote:
> > On Tue, 2020-06-30 at 15:18 -0400, Ben Cotton wrote:
> >> https://fedoraproject.org/wiki/Changes/SID
> >
> >> == 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.
> >
>
I'll be honest, I don't get why this exists. Most folks expect this to
be an aspect of UDisks, so why isn't it?
Especially after http://storaged.org/ merge few years back.
--
Tomasz Torcz “(…) today's high-end is tomorrow's embedded processor.”
tomek(a)pipebreaker.pl — Mitchell Blank on LKML
8:34 a.m.
New subject: Introduce Storage Instantiation Daemon - Fedora 33 System-Wide
Change proposal
On 2020-07-01 14:03, Neal Gompa wrote:
On Wed, Jul 1, 2020 at 8:00 AM Peter Rajnoha
<prajnoha(a)redhat.com> wrote:
>
> On 6/30/20 9:35 PM, Igor Raits wrote:
>> On Tue, 2020-06-30 at 15:18 -0400, Ben Cotton wrote:
>>> https://fedoraproject.org/wiki/Changes/SID
>>
>>> == 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: prajnoha(a)redhat.com
>>
>>> == 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.
>>
>>> == 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)
>>
>> Is this purely about adding some package into the repositories and just
>> to raise awarness that such tool exist?
>>
>
> It's introducing a new mechanism we could use to better handle events for
> storage devices - so yes, also raising awareness. At this moment, adding a new
> package with the daemon and accompanying tools and the functionality disabled
> by default. Then filling it up with modules, then thinking about making it
> enabled by default, getting there step-by-step...
>
I'll be honest, I don't get why this exists. Most folks expect this to
be an aspect of UDisks, so why isn't it?
We (UDisks maintainers) actually plan to use data from SID in UDisks.
UDisks currently gets all the data about storage stack structure and
events from UDev and it's not easy to keep UDisks internal state
consistent and properly react to udev events in a non-racy way. We'll be
happy to "outsource" this to SID. From our point of view, SID will
provide a nice, user friendly layer on top of UDev database and udev
events and it will make our live easier.
8:40 a.m.
New subject: Introduce Storage Instantiation Daemon - Fedora 33 System-Wide
Change proposal
On 7/1/20 2:03 PM, Neal Gompa wrote:
On Wed, Jul 1, 2020 at 8:00 AM Peter Rajnoha
<prajnoha(a)redhat.com> wrote:
>
> On 6/30/20 9:35 PM, Igor Raits wrote:
>> On Tue, 2020-06-30 at 15:18 -0400, Ben Cotton wrote:
>>> https://fedoraproject.org/wiki/Changes/SID
>>
>>> == 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: prajnoha(a)redhat.com
>>
>>> == 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.
>>
>>> == 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)
>>
>> Is this purely about adding some package into the repositories and just
>> to raise awarness that such tool exist?
>>
>
> It's introducing a new mechanism we could use to better handle events for
> storage devices - so yes, also raising awareness. At this moment, adding a new
> package with the daemon and accompanying tools and the functionality disabled
> by default. Then filling it up with modules, then thinking about making it
> enabled by default, getting there step-by-step...
>
I'll be honest, I don't get why this exists. Most folks expect this to
be an aspect of UDisks, so why isn't it?
Udisks doesn't solve instantiation - activation, deactivation (currently a
mixture of various udev rules and various external tools do that in
decentralized way, each subsystem its own way). UDisks enumerates existing
devices and manipulates them. SID provides an abstraction on top of udev to
handle events in a way we need for storage (e.g. the grouping part and the
trigger/action part).
To put it in a picture - udev is at the very bottom level (simple properties,
single devs, simple rules), SID sits on top of udev providing those
extensions, then udisks would be using SID to have better view of layers and
stacks, knowing which devices are usable or not.
--
Peter
8:43 a.m.
New subject: Introduce Storage Instantiation Daemon - Fedora 33 System-Wide
Change proposal
On Wed, Jul 1, 2020 at 9:40 AM Peter Rajnoha <prajnoha(a)redhat.com> wrote:
On 7/1/20 2:03 PM, Neal Gompa wrote:
> On Wed, Jul 1, 2020 at 8:00 AM Peter Rajnoha <prajnoha(a)redhat.com> wrote:
>>
>> On 6/30/20 9:35 PM, Igor Raits wrote:
>>> On Tue, 2020-06-30 at 15:18 -0400, Ben Cotton wrote:
>>>> https://fedoraproject.org/wiki/Changes/SID
>>>
>>>> == 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: prajnoha(a)redhat.com
>>>
>>>> == 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.
>>>
>>>> == 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)
>>>
>>> Is this purely about adding some package into the repositories and just
>>> to raise awarness that such tool exist?
>>>
>>
>> It's introducing a new mechanism we could use to better handle events for
>> storage devices - so yes, also raising awareness. At this moment, adding a new
>> package with the daemon and accompanying tools and the functionality disabled
>> by default. Then filling it up with modules, then thinking about making it
>> enabled by default, getting there step-by-step...
>>
>
> I'll be honest, I don't get why this exists. Most folks expect this to
> be an aspect of UDisks, so why isn't it?
>
Udisks doesn't solve instantiation - activation, deactivation (currently a
mixture of various udev rules and various external tools do that in
decentralized way, each subsystem its own way). UDisks enumerates existing
devices and manipulates them. SID provides an abstraction on top of udev to
handle events in a way we need for storage (e.g. the grouping part and the
trigger/action part).
To put it in a picture - udev is at the very bottom level (simple properties,
single devs, simple rules), SID sits on top of udev providing those
extensions, then udisks would be using SID to have better view of layers and
stacks, knowing which devices are usable or not.
So, I think this cuts to the heart of my question, why not fix UDisks
to solve this problem?
The problem with this complexity is that there's a large universe of
tools that leverage UDisks and would be able to trivially take
advantage of expansion of functionality in UDisks. But by making it a
separate daemon and service with its own lifecycle and state machine,
you have essentially doubled the work everyone has to do to handle
these use-cases. It's not like desktop tools like GNOME Disks or KDE
Partition Manager wouldn't need these features, it's that you are
putting them in what I think is the wrong place (a separate service)
and making it very difficult for those tools to adapt to it.
--
真実はいつも一つ！/ Always, there's only one truth!
8:59 a.m.
New subject: Introduce Storage Instantiation Daemon - Fedora 33 System-Wide
Change proposal
On 2020-07-01 15:43, Neal Gompa wrote:
On Wed, Jul 1, 2020 at 9:40 AM Peter Rajnoha
<prajnoha(a)redhat.com> wrote:
>
> On 7/1/20 2:03 PM, Neal Gompa wrote:
>> On Wed, Jul 1, 2020 at 8:00 AM Peter Rajnoha <prajnoha(a)redhat.com> wrote:
>>>
>>> On 6/30/20 9:35 PM, Igor Raits wrote:
>>>> On Tue, 2020-06-30 at 15:18 -0400, Ben Cotton wrote:
>>>>> https://fedoraproject.org/wiki/Changes/SID
>>>>
>>>>> == 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: prajnoha(a)redhat.com
>>>>
>>>>> == 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.
>>>>
>>>>> == 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)
>>>>
>>>> Is this purely about adding some package into the repositories and just
>>>> to raise awarness that such tool exist?
>>>>
>>>
>>> It's introducing a new mechanism we could use to better handle events
for
>>> storage devices - so yes, also raising awareness. At this moment, adding a
new
>>> package with the daemon and accompanying tools and the functionality
disabled
>>> by default. Then filling it up with modules, then thinking about making it
>>> enabled by default, getting there step-by-step...
>>>
>>
>> I'll be honest, I don't get why this exists. Most folks expect this to
>> be an aspect of UDisks, so why isn't it?
>>
>
> Udisks doesn't solve instantiation - activation, deactivation (currently a
> mixture of various udev rules and various external tools do that in
> decentralized way, each subsystem its own way). UDisks enumerates existing
> devices and manipulates them. SID provides an abstraction on top of udev to
> handle events in a way we need for storage (e.g. the grouping part and the
> trigger/action part).
>
> To put it in a picture - udev is at the very bottom level (simple properties,
> single devs, simple rules), SID sits on top of udev providing those
> extensions, then udisks would be using SID to have better view of layers and
> stacks, knowing which devices are usable or not.
>
So, I think this cuts to the heart of my question, why not fix UDisks
to solve this problem?
The problem with this complexity is that there's a large universe of
tools that leverage UDisks and would be able to trivially take
advantage of expansion of functionality in UDisks. But by making it a
separate daemon and service with its own lifecycle and state machine,
you have essentially doubled the work everyone has to do to handle
these use-cases. It's not like desktop tools like GNOME Disks or KDE
Partition Manager wouldn't need these features, it's that you are
putting them in what I think is the wrong place (a separate service)
and making it very difficult for those tools to adapt to it.
But they will be able to make advantage of the SID change, because
UDisks will use SID instead of UDev.
Also it doesn't really make sense to add the SID functionality to
UDisks. Udisks is a heavyweight daemon and requires DBus to work and
provides high level APIs for tools like Disks and GVFs. UDisks isn't the
right place to do this. It also can't run during early boot and in initrd.
--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
2:50 a.m.
New subject: Introduce Storage Instantiation Daemon - Fedora 33 System-Wide
Change proposal
On Tue, Jun 30, 2020 at 03:18:57PM -0400, Ben Cotton wrote:
== 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
This sounds interesting. Assembling complex storage from udev rules is
not easy, in particular because while it is easy to collect devices
and handle the case where all awaited devices have been detected, it's
much harder to do timeouts or partial assembly or conditional
handling. A daemon can listen to hotplug events and have an internal
state take decisions based on configuration and time and events.
OTOH, based on this description, SID seems to want to take on some
bigger role, e.g. by providing an alternate execution and device
description mechanism. That sounds unnecessary (since udev does that
part reasonably well) and complex (also because support would have to
be added to consumers who currently get this data from udev). I would
love to see a daemon to handle storage devices, but with close
cooperation with udev and filling in the bits that udev cannot provide.
* 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)
I don't think such timeouts are common. Currently the
default worker
timeout is 180s, and this should be enough to handle any device hotplug
event. And if there are things that need to be executed that take a
long time (for example some health check), then systemd units should be used
for this. Udev already has a mechanism to schedule long-running systemd
jobs in response to events. So I don't think we should add anything new
here. So maybe I'm misunderstanding what this point is about?
== 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
Do you plan to handle multi-device btrfs?
Zbyszek
8:23 a.m.
New subject: Introduce Storage Instantiation Daemon - Fedora 33 System-Wide
Change proposal
On 7/1/20 9:50 AM, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Jun 30, 2020 at 03:18:57PM -0400, Ben Cotton wrote:
> == 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
This sounds interesting. Assembling complex storage from udev rules is
not easy, in particular because while it is easy to collect devices
and handle the case where all awaited devices have been detected, it's
much harder to do timeouts or partial assembly or conditional
handling. A daemon can listen to hotplug events and have an internal
state take decisions based on configuration and time and events.
Exactly, that's also one of the areas we'd like to cover here - partial
activations based on policies. This is hard to do within pure udev... or at
least, at the moment, we'd need to put together several *external* pieces
together besides udev to make this working somehow at least. SID will try to
provide the infrastructure to implement this in one place.
OTOH, based on this description, SID seems to want to take on some
bigger role, e.g. by providing an alternate execution and device
description mechanism. That sounds unnecessary (since udev does that
part reasonably well) and complex (also because support would have to
be added to consumers who currently get this data from udev). I would
love to see a daemon to handle storage devices, but with close
cooperation with udev and filling in the bits that udev cannot provide.
Not quite. If it sounds that SID is taking over most of udev's responsibility,
then no. It's trying to build on top of it - still considering udev as
low-level layer for event processing based on simple rules. Then SID adding
abstraction that we need for storage mainly - that is the grouping part, state
recording and delayed trigger/action part.
The issue with udev is that it's concentrated on single device processing and
on current state (yes, we have IMPORT{db}, but that's good for simple records
only). But this is OK as it is a low-level tool.
Also, udev's primary job is to record these single device properties and then
to create the /dev content so these devs are accessible. But there are actions
we don't need to execute within udev context at all - e.g. the device
activation itself. And there are other details where we come short with udev
like the udev rule language itself so if you need to define more complex
logic, you need to call out external commands to do that (and that is just
another fork, just another delay). Even comparing values of two variables is
not possible in udev (you can compare only with a literal constant).
With SID, for backwards compatibility and for udev db readers, we have still
the possibility to export selected information from SID to udev db, if needed
(importing and exporting from/to udev environment is just about using
dedicated namespace we have in SID db). But I think storage subsystems would
go for SID directly if it provides this domain specific information - it's
just adding more details to what udev can see.
What I would probably like to see in the future though is surely a more closer
cooperation of udevd and SID in a way where udevd could still record those
simple generic single device properties as it does today and if it sees that
this is a device that falls under certain domain (like "storage" here), udevd
itself can contact the domain-specific daemon/resource for more information
and then provide that through its interface. Similar logic could apply for
"network" domain, etc. All these domain-specific external resources could be
registered with udevd. But this is for later time and much more discussion...
> * 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)
I don't think such timeouts are common. Currently the default worker
timeout is 180s, and this should be enough to handle any device hotplug
event. And if there are things that need to be executed that take a
long time (for example some health check), then systemd units should be used
for this. Udev already has a mechanism to schedule long-running systemd
jobs in response to events. So I don't think we should add anything new
here. So maybe I'm misunderstanding what this point is about?
Well, timeouts do appear quite often from my experience (reports and
discussions from our support teams). 180s might not be good for all, if you
have hundreds/thousands of devices. And these timeouts are usually quite hard
to debug (most of them are also races of different kinds). Various devices
could also be in suspended state as well, inaccessible. And it's good to have
wider picture of the device group than a single device for us to do proper
actions. Also, on timeouts, udev usually silently drops the event, without a
possibility to execute fallback/correcting actions.
Yes, we can use SYSTEMD_WANTS in udev to instantiate a service outside udev
context (we actually do that in lvm2 with lvm2-pvscan@.service which is
responsible for scanning, making decision whether to activate and then
activate if applicable). The issue here is that systemd unit itself doesn't
have any state - I mean, you can't store any information in it - you need an
external entity to do that, a daemon? Or a database somewhere ...which SID has
all in one place and it tries to centralize/standardize this for storage devs.
When SID processes the event, it has what I call "stage A" and "stage
B" where
the "A" is executing when SID is contacted from within a udev rule. Then
"B"
has all the trigger/action - delayed execution. But important here is that it
uses the same state, same database underneath - it's all in one place for both
stages.
There are also other little issues like that I can bind service unit existence
only to device unit existence, but that does not always apply for storage. The
layers in a stack for various subsystems are defined by existence of the
signature on disk... But that's just another little detail that adds to the
overall storage matters we'd like to solve here.
> == 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
Do you plan to handle multi-device btrfs?
Honestly, I haven't looked at btrfs in much detail how it does the scanning
and activation part exactly. But if it can do a single scan, add to the
detected group and then fire the "activation" (mount) when it's complete
(or
not necessarily complete, but "activatable"), it could be fit into a SID
module. But btrfs is a bit special here - it's a filesystem, not a block dev
while SID is concentrated on block devs primarily. So I'd be a little aware
here, I'd need to check the details here to be sure.
--
Peter
1392
days inactive
1393
days old
10 comments
7 participants
participants (7)
-
Ben Cotton -
Igor Raits -
Neal Gompa -
Peter Rajnoha -
Tomasz Torcz -
Vojtěch Trefný -
Zbigniew Jędrzejewski-Szmek