Re: [BUG] 9.3.4: resync between two Secondaries stuck at 100% - flush request never acked (2 volumes, new-peer before attach)

[Philipp Reisner <philipp.reisner@linbit.com>]

Hi Dominic,

thank you for the excellent report. Your analysis is correct. We
found the same bug independently, and the fix is already in git:

  drbd-9.2: 24374f123a95 ("drbd: keep the dagtag of the last request
            across several attaches")
  https://github.com/LINBIT/drbd/commit/24374f123a95877956c3c95a5080b6afae75b28c

  master:   eec2d913473b (merge of the above into drbd-9.3)
  https://github.com/LINBIT/drbd/commit/eec2d913473bf00370b1049e549f10ac0e6181cd

Only 9.3.4 is affected in practice. It is the first release that
also sends the flush to Secondaries. Earlier releases flush only
Primary peers, and a Primary's own writes move the peer acks forward.

The fix will be in 9.3.5, which we plan to release on November 9th.

If you want to confirm the fix in your VMs before then, the commit
above applies on top of 9.3.4.

Best regards,
Philipp

Am Sat, Oct 24, 2026 at 05:11:08PM +0100 schrieb Dominic Ferard:
> Hello,
> 
> On a two-volume resource, a resync between two Secondaries reaches
> 100% (out-of-sync 0) and never completes: the target stays
> Inconsistent/SyncTarget on both volumes indefinitely. It happens when
> the source was brought up with a plain "drbdadm up" and its second
> volume's peer bitmap_dagtag is higher than its first volume's. We hit
> it in production (two standby hosts, both Secondary while the Primary
> OS is down) and have reproduced it in two VMs. Details, debugfs output
> and our reading of the source are below. Please correct the analysis
> if we have it wrong.
[...]