DRBD 9 Is Coming to the Mainline Kernel, and It Starts by Undoing a Buffer Cap Written for 2008

By Indie Kings | September 27, 2026

Updated September 27, 2026: LINBIT has sent a seven-patch prep series to the Linux block layer, the first step toward putting DRBD 9 in the mainline kernel. The third patch, dated September 23 and addressed to Jens Axboe, raises the driver's socket buffer limit from 10 MiB to 128 MiB and deletes the comment explaining why it was 10 MiB in the first place. The comment read "I don't think that a tcp send buffer of more than 10M is useful", and the commit message says that "was written for the networks of 2008". The mainline driver has been at 8.4.11, released eight years ago, while the out-of-tree version moved to multi-peer replication, RDMA, quorum management and load-balanced TCP.

Image: Distributed Replicated Block Device. Credit: Phoronix.

What was actually sent, and to whom

The headline framing of this story, from Phoronix on September 27, is that a new patch series went out this week in preparation for DRBD 9. The specifics are worth being precise about, because the difference between "DRBD 9 is in Linux" and "a prep series for DRBD 9 went out" is the whole story.

It is the second category. The prep series is seven patches, and it does not contain the DRBD 9 rework. Per Phoronix, the series is "mostly about restructuring the code to better align with the out-of-tree code organization" plus "raising various limits to match the values of DRBD 9".

We have read one of the seven directly. Patch 3 of 7, "drbd: raise the socket buffer size limits to 128 MiB", is dated Wednesday September 23, 2026 at 16:06:04 +0200, from Christoph Böhmwalder, addressed to Jens Axboe with Philipp Reisner, Lars Ellenberg, the drbd-dev list, linux-block and linux-kernel copied. Böhmwalder and Reisner are the two LINBIT developers behind the upstream effort, and Ellenberg is the original DRBD author. [NEEDS VERIFICATION] against the remaining six patches, which we have not read individually, so anything beyond the socket buffer limits is Phoronix's summary rather than ours.

The addressee matters. Axboe maintains the block layer, and this went to linux-block as well as linux-kernel, which means the series is being asked to land in a subsystem tree rather than being sent straight to Linus Torvalds. That is deliberate, and it is the mechanism the series has been using all year.

The patch that leads: a buffer cap written for 2008

This is the patch worth reading in full, because it is a two-line change that is also an indictment of the last eight years.

DRBD exposes two tuning knobs, sndbuf-size and rcvbuf-size, which control the TCP socket buffers used for replication traffic. Both were capped at 10 MiB. The cap carried this comment:

/* I don't think that a tcp send buffer of more than 10M is useful */

The patch raises both to 128 MiB and deletes the comment. The reasoning in the commit message is the part that generalises well beyond storage:

"That was written for the networks of 2008. On today's long-haul 25G+ links the bandwidth-delay product of a single DRBD connection easily exceeds 10 MiB, and the cap then limits replication throughput regardless of how the rest of the stack is tuned."

128 MiB is not a speculative number. Per the commit message, it is "the value DRBD 9 has used for years". Defaults are unchanged, with 0 still meaning the kernel's auto-tuning picks the value, so this only moves the ceiling rather than forcing a size. But the ceiling was the binding constraint. If your replication link has a bandwidth-delay product above 10 MiB, no amount of tuning the rest of the stack helps, because the driver will refuse to hand the socket a larger buffer. The cap was silently capping throughput on exactly the long-haul links that a geographically distributed high-availability cluster is built on.

This is the strongest argument in the whole upstreaming effort and it is not about features at all. It is that the in-tree copy of a driver had fossilised at a set of constants chosen for infrastructure that stopped existing, and nobody could fix it, because the people who understood the problem were working on a different copy of the code.

Eight years of stagnation, and why it happened

The context matters more here than in most upstreaming stories, because the stagnation had a cause and the cause is instructive.

Per LINBIT's own account in April, the version of DRBD in the mainline kernel is 8.4.11, and the most recent release of that line was eight years ago. The out-of-tree version moved on to 9.x. Per a second LINBIT post, development of drbd-9.x started in October 2011, which is where the "10 to 15 years of active out-of-tree development work" figure in Böhmwalder's cover letter comes from.

DRBD 8.4 is a two-node tool. Per LINBIT, it "works only with a single peer; it is a software for two-node failover clusters". The 9.x line replaced the per-device state model with a multi-peer one, and per Philipp Reisner, the team "had to touch on every line of code to introduce the concept that a cluster can have multiple peers". He described it as "like a rewrite, in place".

The reason is stated bluntly in the same post. The reasons for the divergence were "largely commercial": most LINBIT customers run DRBD 9 for its feature benefits, so that is the version the company puts its development resources behind. The in-tree version ended up receiving critical bug fixes only. Asked about it, Böhmwalder, who leads the upstream effort, called the work "important and long overdue".

So the pattern is a familiar one. A driver lives in the kernel, and the users who depend on it most also maintain a better copy out of tree, and the in-tree copy becomes a compatibility obligation that nobody wants to touch. Nobody made a bad decision. The result was still a block replication driver frozen at 2008 network assumptions for eight years.

What DRBD 9 actually adds

For anyone running storage in production, this is the part that determines whether the upgrade is worth planning for. The two are not the same product at different versions.

Capability	Mainline 8.4.11	DRBD 9.x out of tree
Replication topology	Two nodes, one peer, failover	Failover clusters up to 31 peers per volume, 32 nodes counting the primary
Transports	TCP over IP	TCP, RDMA, and a load-balancing TCP transport
Quorum	External, not managed by the driver	Built-in quorum management
Metadata access	Buffered block IO on the metadata device	DAX and PMEM direct access for metadata
On-disk metadata	Single-device superblock layout	Per-peer slot structures tracking bitmap UUIDs and sync state for every peer
Connection model	Per-device state, single socket pair	Explicit control and data streams, sender and receiver node IDs in the handshake
Last release	Eight years ago, per LINBIT	drbd-9.3.4-rc.1 on September 8, 2026, following 9.2.20-rc.1

Two details in that table are worth pulling out.

The peer count is the headline and it is easy to misread. Phoronix describes DRBD 9 as supporting "replication up to 32 nodes" while LINBIT's April post says "up to 31 peers for each DRBD-replicated volume". Those agree: 32 nodes is one primary plus 31 peers. LINBIT also makes the point that most high-availability clusters will use three to five nodes, so 32 is a ceiling rather than a target. If you are planning a three-node cluster, the peer count is not the reason to upgrade.

RDMA is the reason that matters for storage latency budgets. A separate RDMA transport in the series is a different proposition from a faster TCP path, and it is one of the four new transport files the March rework added, alongside plain TCP, load-balancing TCP and a template. Similarly, DAX and PMEM support for metadata access lets the driver address persistent memory directly rather than going through the buffered block layer, which removes a copy from the metadata path on every resync tick. Neither is relevant to most clusters. Both are relevant to the specific clusters that exist because of storage latency, which is the population that notices this work at all.

On the compatibility question, the new feature-flag bits in the rework "advertise these capabilities during negotiation, allowing DRBD to remain wire-compatible with 8.4 peers while enabling the full DRBD 9 feature set when both ends support it". A 9.x node and an 8.4 node can talk, and negotiate down. That is the design detail that makes a rolling migration possible at all.

The series underneath: 45,891 lines and a userspace problem

The seven patches going out now are the visible tip. The substantial work is the 20-patch rework that Böhmwalder posted in March, and its size is the honest measure of what upstreaming this driver involves.

Metric	Value
Patches in the March rework series	20
Files touched	45
Lines added	45,891
Lines removed	16,264
Largest single churn	drbd_receiver.c, 12,258 lines changed; drbd_state.c and drbd_nl.c at 7,724 and 7,248
New files	drbd_transport.c, drbd_transport_tcp.c, drbd_transport_rdma.c, drbd_transport_lb-tcp.c, drbd_sender.c, drbd_legacy_84.c, drbd_meta_data.h, drbd_dax_pmem.c, drbd_config.h
Development history replayed	10 to 15 years, per Böhmwalder, "depending on your way of counting"

The series is structured in a way that is unusual and worth explaining, because it is a deliberate risk-management choice. Its first patch marks DRBD as BROKEN, with the note that the following commits "restructure the driver extensively, and intermediate states do not compile", and its last patch removes the BROKEN marker. The driver is deliberately broken in the tree for the duration of the series so that no kernel builds a half-rewritten replication driver. Anyone tracking CONFIG_BLK_DEV_DRBD over these patches will see it appear and disappear.

The blocker Böhmwalder names is not the code. It is userspace. The v8 and v9 genetlink families are, in his words, "completely incompatible", so old DRBD userspace utilities cannot talk to the new driver at all. The plan is a new genetlink family, "think drbd2", following modern conventions, with both families registered and a compatibility layer for the old one. The prerequisite is converting DRBD's genl_magic macro infrastructure to the kernel's YNL generator, which Böhmwalder expected to be ready by the 7.2 merge window.

That prerequisite has since landed on the out-of-tree side. The drbd-9.3.4-rc.1 release notes from September 8 list as the first change: "Generate the netlink interface code with the upstream YNL generator instead of the genl_magic macro system". So the thing the upstream effort was waiting on exists, in the out-of-tree tree, and the compatibility plan has a working precedent. That is real progress, and it happened in the version nobody is running.

The stated plan is "to submit one new version of this series for every merge window, which should end up in linux-next. Within a few kernel releases, we will hopefully be close enough to get this over the line and submitted for real." The prep series going out now is a step in that cadence, in a subsystem tree, doing the unglamorous work of reshaping the existing 8.4-targeted code toward the 9.x structure so the real patches can apply cleanly later.

The out-of-tree release notes read like a security advisory

If you run DRBD today from the out-of-tree module, the September release notes are the most immediately actionable thing in this story, and they are not pretty.

drbd-9.3.4-rc.1, posted by Philipp Reisner on September 8, follows 9.2.20-rc.1 the previous day. He notes the delay was, "as so often, due to issues in the kernel compatibility system", and that supporting such a broad range of kernel versions is challenging. It was solved. Then this:

Kernel memory corruption by a malicious or man-in-the-middle peer, "sending out-of-range payload, drain or digest sizes, and a divide error caused by bogus peer block sizes". A divide error is a crash, which means a remote peer could take down a node by claiming a block size of zero. This is the item that should drive the upgrade decision for anyone exposing a DRBD link to anything.
Use-after-free of the resource when a connections dump is interrupted, plus a refcount imbalance "flooding the log with put_ldev assertions".
Soft lockups, specifically "the sender thread pinning a CPU while its connection is down, and IRQ-disabled bitmap scans on multi-TiB volumes". The second one is a scalability limit that only appears when your volumes get large, which is the worst time to find it.
A ProtocolError disconnect loop when two volumes of one connection replicate and resync without replication at the same time.
Bitmap lifetime bugs around attach and detach, including a NULL dereference in peer device statistics, a missing bitmap in drbd_set_sync(), concurrent drbd_bm_free() callers, and freeing a bitmap that a later attach republished.
Several data corruption fixes, including a sync target overwriting acknowledged writes with older resync data when the sync source lost the diskless primary, and a peer bitmap being cleared by a running resync being copied for a second peer.
A verify-alg mismatch tolerance change, where the driver now refuses to start an online verify while algorithms differ instead of rejecting the connection outright.

The pattern across all of these is worth naming. Most of them are multi-peer. The 9.x rewrite is what introduced the concepts these bugs live in, so a codebase rewritten in place over fifteen years produces a burst of multi-peer correctness and security bugs while it settles. That is not an argument against the rewrite. It is an argument for reading your out-of-tree release notes rather than running rc builds on production links, and for the merge review process that LINBIT says this work is already benefiting from.

The objections on the list, and the answer

A patch series of this size does not go through review unchallenged, and the objections on the list are legitimate and worth reading in Böhmwalder's reply rather than skipping to.

Reviewers raised two specific process points in April: whether the kerneldoc nits and assigned-but-unread tags would be fixed and a new version sent, and the observation that the series "doesn't actually apply to for-7.1/block, patch 12 fails". A further reply questioned the whole approach, arguing that a replacement of this scale going in without review is "known to cause bugs and regressions". [NEEDS VERIFICATION] on individual attribution, which the archives we reached do not make reliable, so we are not naming who wrote which.

Böhmwalder's response is the substantive part. The goal is "to sync the two drbd code bases", and he framed it as the "usual" pattern of an in-kernel driver being neglected with users pushed to the out-of-tree one, "which is highly annoying". On the review question he was explicit that "the intent is not to push to mainline right now, but rather give it -next exposure without running into conflicts between the trees", that for-7.x/drbd will be rebased as needed, and that it sits in for-next "for the stated reason".

That is the correct posture for a patch series this size, and it is also an admission that the rework is not ready. A driver in for-next, rebased as needed, exposed to build and test coverage without being submitted, is the standard way to land something that would otherwise be rejected outright. Böhmwalder's own cover letter says there "are still probably imperfections" and asks for feedback.

LINBIT also makes a quieter argument that the merge review is already producing value even before a merge. The process puts DRBD 9 "through independent analysis from Linux power users (kernel maintainers)", gets it "tested on exotic CPU architectures", and runs "different continuous integration (CI) bot tests outside of the LINBIT development team's own testing". And the maintenance argument is the one Böhmwalder puts plainly: "It's so much easier if you already closely track upstream development. This is because the divergence between in-tree and out-of-tree is minimal, so you don't need to adapt the patches much and can pretty much just carry the upstream patches 1:1 to out-of-tree." He also expects the team to adopt an upstream-first workflow, with the primary target becoming the mainline kernel and patches trickling down, while customer-specific fixes bypass it so the customer still gets the fix first.

What to do if you run DRBD today

The practical position, stated plainly.

If you are on the mainline kernel's 8.4.11, nothing has changed for you and the 128 MiB cap is still there. Do not plan a capacity increase on the assumption that a prep series has landed. The series is seven patches of restructuring and limit raises, the driver is deliberately marked BROKEN partway through the larger rework, and Böhmwalder's own plan is one new version per merge window with the real submission still ahead. Phoronix's framing is that the major update "has yet to land", and the current development cycle has moved past the 7.2 window that LINBIT named in April as the most optimistic landing point.

If you are on the out-of-tree module, read the 9.3.4-rc.1 and 9.2.20-rc.1 notes before anything else. The malicious-peer memory corruption and the divide error are the two that justify acting rather than noting. If you expose a DRBD link to a network you do not fully control, the mitigation is to treat the peer as untrusted until you are on a release that includes those fixes.

If you are planning a cluster design, the roadmap is the news. 31 peers, RDMA, DAX metadata and built-in quorum are all real and all shipping in the 9.x line today, from the same code that is trying to become 8.x-plus in the mainline. A design that needs three to five nodes and does not need RDMA has no reason to care about upstreaming at all, and should not let a patch series make it think otherwise.

LINBIT publishes an "Upgrading DRBD from 8.4 to 9.x" section in the DRBD 9 User Guide, and describes the process as having many steps but being straightforward, with systems administrators having already done it. We have not read that guide and are not reproducing vendor instructions. The compatibility design that matters is the negotiation one: a 9.x node and an 8.4 node stay wire-compatible and negotiate down, which is what makes a staged migration rather than a flag day possible.

FAQ

What exactly did LINBIT send to the Linux kernel this week?

A seven-patch prep series, not the DRBD 9 rework itself. We have read patch 3 of 7 directly, "drbd: raise the socket buffer size limits to 128 MiB", dated September 23, 2026 and addressed to Jens Axboe with linux-block and linux-kernel copied. Per Phoronix, the series is mostly restructuring the in-tree 8.4-targeted code to match the out-of-tree code organisation, plus raising various limits to match DRBD 9 values. We have not read the other six patches individually, so their contents are Phoronix's summary rather than ours.

Why does raising a buffer cap from 10 MiB to 128 MiB matter?

Because on long-haul 25G+ links the bandwidth-delay product of a single DRBD connection exceeds 10 MiB, and the cap then limits replication throughput no matter how the rest of the stack is tuned. The old cap carried the comment "I don't think that a tcp send buffer of more than 10M is useful", and the patch message says that "was written for the networks of 2008". 128 MiB is the value DRBD 9 has used for years, and defaults are unchanged, so 0 still means kernel auto-tuning. This moves the ceiling only.

Is DRBD 9 in the mainline kernel now?

No. Phoronix states the major update "has yet to land", and the larger March rework deliberately marks the driver as BROKEN for the duration of the series because intermediate states do not compile, re-enabling it in the final patch. Böhmwalder's stated plan is one new version of the series per merge window to get exposure in for-next, with the real submission still ahead. LINBIT named Linux 7.2, planned for September or October 2026, as the most optimistic case, and the development cycle has moved past that window.

How many nodes can DRBD 9 replicate to, and is the number the same as the peer count?

Not the same number, and the two sources are consistent once you account for the primary. Phoronix says "replication up to 32 nodes". LINBIT says "failover clusters up to 31 peers for each DRBD-replicated volume". Thirty-two nodes is one primary plus 31 peers. LINBIT also notes that most high-availability clusters will use three to five nodes, so the ceiling is a limit rather than a design target.

What is the security situation for anyone running DRBD 9 out of tree?

Serious enough to read the release notes. The drbd-9.3.4-rc.1 notes from September 8, 2026 list "kernel memory corruption by a malicious or man-in-the-middle peer sending out-of-range payload, drain or digest sizes, and a divide error caused by bogus peer block sizes", which is a remote crash as well as memory corruption. The same notes fix a use-after-free of the resource, soft lockups including IRQ-disabled bitmap scans on multi-TiB volumes, a ProtocolError disconnect loop, several bitmap lifetime bugs around attach and detach, and two data corruption bugs involving resync and bitmap copying.

Will DRBD 9 break my existing userspace tools?

Not eventually, and yes temporarily during the transition. Böhmwalder states the v8 and v9 genetlink families are "completely incompatible" and identifies this as the main remaining blocker. The plan is a new genetlink family, "think drbd2", with both registered and a compatibility layer for the old one, which requires first converting DRBD's genl_magic macros to the YNL generator. That conversion landed out of tree in 9.3.4-rc.1. Separately, the rework's new feature-flag bits keep a 9.x node wire-compatible with an 8.4 peer so both can negotiate, which is what allows a staged rather than all-at-once migration.

Bottom Line

The most useful thing in this story is a deleted comment. A driver in the Linux kernel had a TCP send buffer capped at 10 MiB, with an inline comment dismissing anything larger as useless, and the reason is that nobody with the knowledge to raise it could touch the tree, because the people who understood it were maintaining a different copy out of tree for commercial reasons. Eight years and one rewrite later, the cap is being lifted to 128 MiB because the bandwidth-delay product of a single replication link on a 25G long-haul connection exceeds the old limit, which means the cap was throttling throughput on exactly the links that geographically distributed high availability is built on. That is a stale constant, not a missing feature, and it is a more damning indictment of the state of the in-tree copy than the fifteen years of divergence behind it.

What the seven patches going out this week are is maintenance infrastructure, not news. They reshape the 8.4-targeted code in the mainline to match the out-of-tree organisation and lift assorted limits to DRBD 9 values, so that the real patches apply cleanly later. Böhmwalder's own cover letter describes the March 20-patch rework as replaying 10 to 15 years of out-of-tree development across 45 files and 45,891 insertions, deliberately marking the driver BROKEN for the duration because intermediate states do not compile, and blocked on a userspace genetlink incompatibility that requires a new drbd2 family and a YNL conversion. The plan is one version per merge window into for-next, with the real submission still to come, and the 7.2 window LINBIT called the most optimistic case in April has passed. Anyone reading the "DRBD 9 is coming to Linux" framing and planning around it is about six merge windows early.

For people actually running the thing, the September out-of-tree releases matter more than the upstreaming. The 9.3.4-rc.1 notes describe kernel memory corruption reachable by a malicious or man-in-the-middle peer sending out-of-range payload and digest sizes, plus a divide error from bogus peer block sizes that is a remote crash, alongside a resource use-after-free, soft lockups that only appear on multi-TiB volumes, and two resync data corruption bugs. Most of those live in the multi-peer machinery the 9.x rewrite introduced, which is what a fifteen-year in-place rewrite looks like while it settles, and it is the clearest argument in the whole story for why the merge review is worth doing slowly.

The upside, when it arrives, is a block replication driver in the mainline that does what the out-of-tree one has done for over a decade: failover clusters up to 31 peers, RDMA alongside TCP, load-balanced TCP, built-in quorum, and DAX and PMEM direct access for metadata. A 9.x node negotiates down against an 8.4 node, so the migration can be staged. And Böhmwalder's actual argument is not a feature list, it is that keeping divergence near zero means the company can carry upstream patches through one to one instead of manually backporting every kernel change, which is the boring operational win that determines whether a driver stays alive or quietly dies the way this one nearly did. Two of those three things matter to a three-node cluster, and all three matter to a cluster with RDMA fabric. Neither matters yet to anyone reading the mainline tree, and the honest summary is that the 2008 constant is being removed, one merge window at a time.

Source: Phoronix, New Patch Series Working Toward DRBD 9 Support In The Linux Kernel by Michael Larabel, September 27, 2026. Patch detail from linux-kernel, [PATCH 3/7] drbd: raise the socket buffer size limits to 128 MiB by Christoph Böhmwalder, September 23, 2026, and [PATCH 00/20] DRBD 9 rework of March 27, 2026. Background from LINBIT's April 2026 posts on the upstream effort and on merging DRBD-9.3, and the drbd-9.3.4-rc.1 release notes of September 8, 2026. Items marked [NEEDS VERIFICATION] are the six prep patches we did not read individually and the review-thread attribution we could not establish from the archives we reached