stratisd: a D-Bus daemon that assembles XFS pools out of block devices

ZFS-like features without a new filesystem

stratisd is a daemon that manages a pool of block devices to create flexible filesystems, and the design decision that explains everything else is that Stratis provides ZFS and Btrfs style features by integrating layers of existing technology rather than writing a new filesystem. Those layers are Linux's devicemapper subsystem and the XFS filesystem. The daemon manages collections of block devices and exports a D-Bus API, and the stratis command line tool from the companion stratis-cli repository provides a stratis command which itself uses that D-Bus API to communicate with the daemon. So the architecture is a privileged service with a stable programmatic interface, and everything a user does goes through the command line tool rather than through the daemon directly. The primary language is Rust, which the project gives as the reason the implementation stays small and correct and does not require shipping with a large language runtime.

Building it and running it as root

Stratisd requires Rust and Cargo to build, and these may be available through your distribution's package manager, or you can install and update the toolchain with Rustup. Once the toolchain and other dependencies are in place, you run make build to build, and then run the stratisd executable as root. The Makefile gives you more than that, and the feature matrix in the manifest is worth reading because it explains why the build has so many switches. The stratisd binary requires the engine feature, stratisd-tools requires engine and extras, and both stratisd-min and stratisd-min are separate minimal binaries that also require the min feature, while the two udev helper binaries require udev_scripts. The workspace uses edition 2021 and sets the lowest supported Rust toolchain to 1.87.0, and the manifest version is 3.10.0 while the most recent tagged release listed is stratisd-v3.9.3 from the end of August 2026, with the last push on 2026-10-19.

The D-Bus policy file is a hard requirement

This is the configuration step that trips people up, and the documentation is direct about it. Stratisd runs as root and requires access to the D-Bus system bus, so in order to work properly a D-Bus configuration file must exist to grant that access. It is either installed by distribution packaging, or you install it manually by copying stratisd.conf to the /etc/dbus-1/system.d/ directory. The stratisd.conf file is in the repository root for exactly that reason. Without it the daemon starts and then cannot talk to the bus, which is a confusing failure because the process itself is running. The rest of the configuration is about logging. There is a command line option for the log level, which sets the level for the stratisd components only, and for finer grained control over the log level of any stratisd component or dependency you use the RUST_LOG environment variable, with the documentation pointing at the env_logger crate for the details.

The Makefile is a matrix of build modes

The Makefile is where the project's engineering discipline shows, and it is worth reading as a whole rather than as a list of targets. Several environment variables change what the build does. Setting AUDITABLE switches the build to auditable build with clippy and rustc replaced by their auditable versions, which is the reproducible build path. Setting MINIMAL switches to minimal-versions, which resolves dependencies to their lowest permitted versions, so a build that works with minimum versions proves the declared minimums are real. A PROFILE variable adds instrumentation coverage flags, CAP_LINTS passes a lints cap, and TARGET passes a rust target. Clippy options change with CLIPPY_FIX, adding the fix and allow dirty flags, and the audit options are set to deny warnings. The install paths are all derived from a PREFIX of /usr, with separate directories for the executable, data, udev rules, man pages, systemd units and dracut modules, and a PROFILEDIR of release by default, with debug dropping the release flag.

Formatting and linting are enforced by CI

Two gates sit between a contributor and a merged pull request, and both are version sensitive, which is why the toolchain note matters. Stratisd uses rustfmt to enforce consistent formatting, and pull requests must pass the fmt task in the CI to be merged, with make fmt the command to check your changes locally. It also uses clippy to detect Rust lints, and pull requests must pass the clippy task, checked with make clippy. Both tools give slightly different results on different compiler versions, and the documentation says to make sure you use the current development version, and the recommended development toolchain is usually the Rust stable version though it may lag it slightly. The recommended toolchain version can be determined by inspecting the CI configuration files for the project, which is a slightly unusual way to learn a required version but avoids the document going stale.

Testing happens at two levels, one of them destructive

Stratisd is tested in two ways, and the split is a direct reflection of what the daemon does. The first way makes use of the Rust test infrastructure and has more access to stratisd internals. The second way makes use of the stratisd D-Bus interface, which is how you test the thing users actually call. The first of those has two modalities of its own. Safe unit tests can be run without affecting your storage configuration, and the unsafe unit tests may create and destroy devices during execution, with the setup steps and how to run them described in README_tests.md. The safe ones run with:

$ make test

The D-Bus based tests are described separately in the tests/client-dbus directory with its own README, and the repository also carries an fmf directory, a tests-fmf directory, a udev directory and a dracut directory, which point to a test matrix driven by the fmf tooling and to the udev and dracut integration that ships with the daemon. A make build-tests target exists so developers can compile the tests without running any of them.

MPL 2.0, a mailing list and a packaging pipeline

The licensing is MPL 2.0, and the rule about contributions is the standard file-level copyleft: all contributions retain ownership by their original author but must also be licensed under the MPL 2.0 to be merged. That is worth noting for a daemon that is packaged into distributions, since it means a patch to a file is published under the same terms while the rest of the codebase is not affected. Development happens through GitHub pull requests and issue tracking, and patches or bug reports may also be sent to the stratis-devel mailing list on lists.fedorahosted.org if you prefer. The tree is set up for distribution packaging rather than as a plain source project, with a .packit.yaml for Packit, systemd unit directories, udev rules, dracut modules, a gitlint configuration and a .yamllint configuration, and a CHANGES.txt rather than a changelog file. There is also a plans directory, which is where the roadmap documents live, and the licence field in the manifest matches the MPL 2.0 named in the readme.

Editorial conclusion

stratisd suits a Linux administrator who wants a single command to combine several disks into one flexible filesystem with snapshots, without running a kernel filesystem driver of their own. It does not suit a system without D-Bus system bus access, since the daemon requires root and a configuration file granting bus access, and it does not suit someone who wants the control a real volume manager gives. Before you deploy it, read the configuration section, because the D-Bus policy file has to be in place or the daemon cannot talk to the bus, and note that the daemon runs as root and manages real block devices.

Frequently asked questions

Official sources

1. License: MPL-2.0
2. Project website
3. README
4. Releases
5. stratis-storage/stratisd on GitHub