Distributed Replicated Block Device (DRBD) announcements
 help / color / mirror / Atom feed
From: Philipp Reisner <philipp.reisner@linbit.com>
To: drbd-announce@lists.linbit.com
Subject: drbd-9.3.0
Date: Mon, 01 Dec 2025 17:16:09 +0100	[thread overview]
Message-ID: <86qzte41py.fsf@linbit.com> (raw)


Dear DRBD-users,

I'm proud to announce drbd-9.3. The most recent branch that adds new
functionality.
Some of it needed much more time to ripen than I expected when I did the
first release candidate. But now, it feels good. We can't make it
produce any issues in our automated testing: not with the CI tests, not
with the nightly stability tests, nor with the endurance tests.
We rolled out the 6th release candidate to our internal production
systems, in line with the eat-your-own-dogfood methodology. It is
running fine. It is ready for prime time.

The two most noticeable features are: resync without replication, and
variable bitmap block sizes.
Resync without replication speeds up the resync process, especially on
volumes under heavy application I/O.
The variable bitmap block size allows you to tune DRBD to use a single
bit in the out-of-sync bitmap for more than 4KiB of storage (e.g., 8KiB,
16KiB, ... 1MiB), reducing DRBD's memory footprint.


9.3.0 (api:genl2/proto:86-101,118-123/transport:19)
--------
 * was forked off between 9.2.12 and 9.2.13
 * Implemented resync without replication and made it the default; the
   previous (drbd-9.2 and earlier) behavior is still available via a
   config option. With that, the resync operation begins with
   mirroring of application writes disabled, and it performs multiple
   resync passes, clearing bits in the bitmap. It enables application
   write mirroring when the resync is nearly complete. That reduces
   the I/O load during resync, and in most cases, it reduces resync
   time.
 * Implemented support for bitmap granularity between 4k and 1M,
   including exchanging bitmaps with peers with a different bitmap
   block size
 * Give filesystems mounted on DRBD a chance to bring their on-disk
   representations into a consistent state before suspending I/O.
 * Add support for omitting bitmap allocation for standalone devices
 * Explicit config option for drbd8-api-compatibility mode
 * Dropped support for RHEL7 and support for kernels older than 3.10.
 * All fixes from 9.2.13 to 9.2.16
 * Compatibility with Linux-6.18


https://github.com/LINBIT/drbd/commit/f5e0e7ebfa6112db11a7fa0bc755af85c89d968d
https://pkg.linbit.com//downloads/drbd/9/drbd-9.3.0.tar.gz

Cheers,
 Philipp

                 reply	other threads:[~2025-12-01 16:16 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86qzte41py.fsf@linbit.com \
    --to=philipp.reisner@linbit.com \
    --cc=drbd-announce@lists.linbit.com \
    --cc=drbd-user@lists.linbit.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox