The latest version of the Stratis local storage management utility now supports per-pool encryption of devices that form a pool data tier. It is possible to encrypt the pool or to activate the pool’s individual encrypted devices using a key in the kernel keyring.
stratisd daemon of version 2.1.0 provides the following new D-Bus
org.storage.stratis2.manager.r1- Provides an extended
CreatePoolmethod to support an optional argument for encryption. Also, it supplies a number of methods for key management.
org.storage.stratis2.pool.r1- Supports explicit initialization of a cache tier. Also, it supports a new
org.storage.stratis2.FetchProperties.r1- Supports an additional
org.storage.stratis2.Report.r1- Supports a set of ad-hoc reports about Stratis. The interface and the names by which the reports can be accessed are not stable. Any report is only in the JSON format.
stratis command-line utility of version 2.1.0, requires
the same version. Users can observe the following changes in
The command for creating pools now allows also encryption.
init_cachecommand for initializing a cache.
keyis a new sub-command for key management tasks.
reportis a new sub-command for displaying of reports generated by
The output of the
pool listcommand now includes a Properties column. Each entry in this column is a string encoding the following properties of the pool:
Whether or not it has a cache.
Whether or not it is encrypted.
All commands now verify that
stratisis communicating with a compatible version of
stratisdis of incompatible version,
stratiswill fail with an appropriate error.
The following are significant implementation details:
Each block device in an encrypted pool’s data tier is encrypted with a distinct, randomly chosen Media Encryption Key (MEK) on initialization.
All devices from a single encrypted pool share a single passphrase that is supplied through the kernel keyring.
This release requires the
cryptsetuputility of version 2.3.
Storage Instantiation Daemon (SID) provides a system-level infrastructure for convenient handling of storage-device-related events through modules provided by other developers.
Fedora 33 introduces a package with SID. At first, this daemon will be disabled by default and will provide limited functionality. Further Fedora updates will enhance the SID functionality.
The general theme running across benefits of this Fedora update is
centralization of solutions that address storage issues with
This change brings the following benefits:
Identifying specific Linux storage devices and their dependencies
Collecting information and state tracking
Central infrastructure for storage event processing
Improving recognition of the storage events and their sequences
Centralized solution for delayed actions on storage devices and groups of devices
Single notion of device readiness shared among various storage subsystems
Enhanced possibilities to store and retrieve storage-device-related records when compared to the
Centralized solution for scheduling triggers with associated actions defined on groups of storage devices
Direct support for generic device grouping
dmraid package is necessary for supporting firmware-based Redundant
Array of Independent Disks (RAID) sets of non-Intel® systems and Fedora only
support these RAID sets when they are already configured in BIOS during the
dmraid package provides the
dmraid-activation.service that required
an obsoleted service
systemd-udev-settle.service in the default Fedora
systemd-udev-settle.service service waited a long time
for detection of all devices. As a result, a system booting was
To solve this problem,
dmraid-activation.service now disables itself if no
supported RAID sets are found when the service runs for the first time.
The default partitioning scheme on Fedora Workstation now uses Btrfs. See Distribution-wide Changes for more information.