DRBD 9 replicates a block device in the kernel, and the compat layer is the hard part

Block level replication, up to 32 nodes, in the kernel

DRBD is a kernel level replicated block device for GNU/Linux, developed by LINBIT. The mechanism is that it synchronises storage across up to 32 nodes over TCP/IP or RDMA, with replication that can be synchronous or asynchronous. The 9 series adds multi-node topologies, quorum, and automatic promotion, and the module also acts as the data plane for LINSTOR, LINBIT's software defined storage manager. Two things follow from that positioning. First, this repository is not a storage system on its own, it is the replication layer that a block device is built on, and the interesting consumers of it are higher layers that need the same storage presented consistently on several machines. Second, since the replication happens in the kernel, the application above sees an ordinary block device and does not need to know that two machines are involved.

The compat system is what makes an old kernel buildable

The source tree always targets the newest upstream kernel, and backward compatibility is handled automatically by a Coccinelle based compat system, which means semantic patches are generated for kernels that predate the current APIs. The oldest kernel supported is 4.12.14, the one shipped with SLES 15 SP1, and the README lists the floor per distribution:

| Distribution | Minimum version | Minimum kernel | |--------------------|-----------------|--------------------| | RHEL | 8.0 | `4.18.0-80` | | SLES | 15 SP1 | `4.12.14-197` | | Debian | 10 (Buster) | `4.19.0` | | Ubuntu | 18.04 (Bionic) | `4.15.0` |

RHEL-compatible distributions, meaning AlmaLinux, Rocky Linux and Oracle Linux, use similar kernels and are generally supported as well. The compatibility work is not always local, because the build can call out to what LINBIT calls a spatch as a service, configured in the Makefile:

SPAAS ?= true
SPAAS_URL ?= https://spaas.drbd.io

If you have no internet access, you need a local Coccinelle installation instead. The README also notes that development generally stays up to date with kernel compatibility, so most new distribution kernels should start working within the next DRBD release, and that a module built for a slightly older kernel within the same RHEL minor may also work. For Red Hat based distributions a live overview of tested kernels is published at kernels.drbd.io.

Build from a tarball unless you are developing

There are two build paths and they have different prerequisites. The release tarballs ship pre-generated compat patches for common distribution kernels, so in most cases make just works, and for other kernels the build automatically uses the spatch as a service to generate the right patches. Building from git is for development and it requires Coccinelle, spatch version 1.1.1 or newer, which most distributions ship in older versions. The README gives three ways out of that bind. Use a recent kernel, in which case no compat patches are needed and spatch is not required at all. Use the Fedora Coccinelle package, which is recent enough to build DRBD, with an explicit warning that the Ubuntu Coccinelle package, despite reporting the same version number, is not able to build DRBD. Or build spatch from source. The warning about Ubuntu is the kind of detail that costs an afternoon if you do not read it first, since the version numbers match and the failure looks like a DRBD problem rather than a tooling one.

The packaged builds are for LINBIT customers, not in this tree

If you want DRBD as a package, this repository is not where you get it. The README states that the simplest way to use DRBD is to install the pre-built rpm and deb packages, and that those are available to LINBIT customers, with a contact link for more information. The same applies to release tarballs, which are provided by LINBIT rather than built from the repository. That distinction is worth understanding before you plan a deployment: the source here is open, the supported packaging is a commercial product, and the documentation is hosted at docs.linbit.com, with the user guide for the 9 series linked from the repository. The repository also has a section headed Support that points to LINBIT's support contact for further products and professional support. The licence is GPL-2.0, with the COPYING file at the root and the same terms spelled out in the Makefile header.

Git tags are snapshots, not releases

The Releases section is short and unusually blunt. Releases generated by git tags on GitHub are copies of the git repository at the given time, and the README says you most likely do not want to use them. The reason given is that they might lack generated man pages, the configure script, and other generated files, and it points to the tarballs provided by LINBIT for anyone who wants to build from a tarball. This is easy to get wrong, because a tag looks exactly like a release in most automation. If a pipeline fetches a tag and runs the build, it can fail on a missing generated file with an error that has nothing to do with your configuration. The safer pattern is to take a tarball from the vendor, or to build from git and generate what the build expects.

Contributions go to mailing lists, not to pull requests

The contributing section rules out the GitHub workflow that most open source projects now default to. Development is coordinated via mailing lists at lists.linbit.com, and the README states that they currently do not intend to use GitHub issue tracking or pull requests. If you plan to send a patch, your route is the mailing list, and a pull request opened on the repository is not the expected channel. The quality bar is the Linux kernel style, enforced by a pre-commit hook that the README tells you to install:

curl -L https://github.com/torvalds/linux/raw/master/scripts/checkpatch.pl | sudo tee /usr/local/bin/checkpatch.pl | wc
sudo chmod +x /usr/local/bin/checkpatch.pl
curl -L https://github.com/torvalds/linux/raw/master/scripts/spelling.txt | sudo tee /usr/local/bin/spelling.txt | wc
sudo touch /usr/local/bin/const_structs.checkpatch
cp misc/pre-commit misc/prepare-commit-msg misc/commit-msg .git/hooks/

So the checkpatch script, the kernel spelling list and the hooks from the misc directory do the style checking before a commit is ever made. The repository is mirrored in GitLab as well, judging from the .gitlab directory and .gitlab-ci.yml at the root, so the mailing list and the GitLab instance are the places where the work happens.

The Makefile builds a matrix of container images

Beyond the kernel module itself, the repository carries a lot of supporting machinery. The Makefile drives a container image matrix through a registry and an architecture variable:

DOCKERREGISTRY := drbd.io
ARCH ?= amd64
DOCKERIMAGES = rhel8 rhel9 rhel10 focal jammy noble resolute flatcar amzn2 sles15

The image list spans the distributions the README lists as supported, plus Flatcar and Amazon Linux 2, and each one has a dockerimage target. The rest of the tree explains the rest: drbd-kernel.spec for the RPM build, a debian/ directory for the Debian packaging, filelist-suse for the SUSE file list, checks/ for the test suite, sbom/ for a bill of materials file, Documentation/ for the kernel documentation sources, a ChangeLog, and a docker/ directory. A system that has to build against this many kernel and distribution combinations is a system where the build tooling is a first class part of the project rather than an afterthought.

Where DRBD is the wrong tool

The clearest boundary is that DRBD replicates blocks, not files and not application semantics. It presents a block device that is synchronised between machines, and whatever filesystem you put on top is what your application sees, including any consistency rules that filesystem imposes. That is a different model from a tool that replicates files and resolves conflicts for you, and it is a different model from backup. If you need per file granularity, conflict resolution, or a guarantee that an application level transaction is replicated as a unit, a block device underneath does not give you that. The second boundary is the compat policy, and it is stated bluntly: each release targets the latest upstream kernel at the time, compat is not backported to older DRBD releases, and if your kernel is newer than what a release was tested against, you may need to wait for the next release or do the compat work yourself. With the repository's last push on 2026-10-20 and no GitHub releases, that waiting is on the release cadence of the vendor, not on the commit log you can see here.

Editorial conclusion

Use this repository if you are building a replicated block device on Linux and you need the kernel module source, particularly if you have to support a distribution kernel older than your own, because the Coccinelle compat system and the pre-generated compat patches in the release tarballs are the reason this code is worth reading. Do not start here if you want a supported package, since the pre-built rpm and deb are described as available to LINBIT customers, and do not treat git tags as releases, because the README warns they are copies of the repository that may lack generated files. Before building, check the minimum kernel listed for your distribution, decide whether you have Coccinelle 1.1.1 or newer available, and read the compat policy, since compat is not backported to older DRBD releases.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. LINBIT/drbd on GitHub
4. Project website
5. README