LINBIT submits DRBD 9 multi-peer rework to mainline kernel
A 20-patch series aims to close a decade-plus gap between the out-of-tree module and the single-peer code still shipped in-tree.
LINBIT has posted a large patch series to the Linux kernel mailing list that brings the long-out-of-tree DRBD 9 multi-peer design into mainline, after more than a decade of divergent development.
DRBD (Distributed Replicated Block Device) has shipped in the kernel for years in its older single-peer form. The out-of-tree module, meanwhile, grew a full multi-node replication model, finer state handling, and new admin interfaces. Christoph Böhmwalder, posting the series for a for-7.x/drbd path into linux-next, described the submission as replaying roughly ten to fifteen years of that work and acknowledged the size of the diffs.
The practical stakes are compatibility and capability. Existing drbd-utils keep working: the driver still serves the original generic netlink family at version 1 with single-peer semantics. Multi-peer administration is exposed only through a new family, drbd2, specified with modern genetlink conventions. An optional compatibility switch preserves the old /proc/drbd view and 8.4-era on-disk metadata so deployments are not forced off existing tooling overnight.
Architecturally the series replaces the monolithic 8.4 state machine with transactional, cluster-visible state changes, including two-phase commit for connect, disconnect, role, and resize operations, plus quorum with tiebreaker support so even-sized clusters can suspend or fail I/O when they lose majority. Replication, resync, and request tracking move to a per-peer model; locking is broken into finer resource, connection, and device scopes; and conflict detection between application and resync I/O becomes interval-based rather than coarse extent locking. A DAX path for metadata on persistent memory is included when that config is enabled; RDMA and load-balancing TCP transports are deferred to later submissions.
If the branch matures in linux-next as planned, mainline users would finally get the multi-peer DRBD that production out-of-tree stacks have relied on for years, without breaking the tools and semantics the in-tree driver has always exposed.