From: Kyrylo Biryuk <illofspeed@gmail.com>
To: dm-devel@lists.linux.dev
Cc: agk@redhat.com, snitzer@kernel.org, mpatocka@redhat.com,
bmarzins@redhat.com, hare@suse.de, dlemoal@kernel.org,
linux-kernel@vger.kernel.org
Subject: [PATCH v3 0/3] dm zoned: fix two idle reclaim problems
Date: Sun, 11 Oct 2026 19:54:47 +0200 [thread overview]
Message-ID: <20261011175450.952-1-illofspeed@gmail.com> (raw)
Changes in v3:
- Patch 2: reworded the comment and dropped the redundant
dmz_nr_cache_zones() test, so the condition fits on one line
(Damien Le Moal). Patches 1 and 3 are unchanged.
- From and Signed-off-by now carry my full name instead of the GitHub
handle, as you preferred on v2. Thanks for checking.
Changes in v2:
- No code changes; only my author address changed.
These patches fix two problems in dm-zoned's reclaim worker, found while
running md RAID5 on three dm-zoned targets on 27 TB host-managed SMR drives
(WD Ultrastar DC HC680), each target with a regular cache device.
1. On a target with cache zones and no free sequential zone, an idle
target keeps copying random zones into other random zones, forever
(patch 2; patch 1 makes the resulting -ENOSPC back off instead of
spinning). After a full md rebuild every chunk is mapped, so this
happens right after a rebuild: the idle member read and wrote about
72 MB/s nonstop for hours.
2. After a reclaim pass that ends while the target is busy, the idle poll
is never re-armed, so zones filled under load are not reclaimed when the
target goes idle (patch 3). Users notice it as "the buffer never drains";
the workaround has been a timer sending "dmsetup message <dev> 0 reclaim".
Testing: the three patches were built as an out-of-tree dm-zoned module for
7.2.6 (the changed code is identical in current master) and tested
- on emulated host-managed drives (tcmu-runner ZBC handler) in a VM: the
idle copy loop reproduced with the stock module (340 MB/s on an idle
target, zone counters unchanged), 0 MB/s with the patches;
- on the three real drives since 2026-10-05: crash test, three 1.5 TiB
write benchmarks, and eight conversions between single-device and
cache-device layouts; emptied zones were reclaimed within minutes of the
targets going idle without the reclaim timer.
- with a reproducer that needs no special hardware (scsi_debug zbc=managed,
64 MiB zones, plus a 1 GiB loop cache device): stock module ~600 MB/s of
read+write on the idle target with unchanged zone counters, patched
module 0 MB/s:
https://github.com/illofspeed/synology-host-managed-smr/tree/main/repro
Not done: a test on current master itself (only 7.2.6), and a rebuild onto a
cached member with the patches (the first problem was seen after a rebuild
with the stock module).
Related, not addressed here: the double-free in dmz_load_sb() reported on
dm-devel on 2026-05-30.
The problems were found and the patches written with the help of an AI
coding assistant (hence Assisted-by); the analysis, the tests on real
hardware and this description were reviewed by me.
Kyrylo Biryuk (3):
dm zoned: back off when reclaim finds no destination zone
dm zoned: do not reclaim a random zone into another random zone
dm zoned: keep polling for idle reclaim after a reclaim pass
drivers/md/dm-zoned-reclaim.c | 27 +++++++++++++++++++++++++--
1 file changed, 25 insertions(+), 2 deletions(-)
--
2.47.3
next reply other threads:[~2026-10-11 17:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-11 17:54 Kyrylo Biryuk [this message]
2026-10-11 17:54 ` [PATCH v3 1/3] dm zoned: back off when reclaim finds no destination zone Kyrylo Biryuk
2026-10-13 9:32 ` Damien Le Moal
2026-10-11 17:54 ` [PATCH v3 2/3] dm zoned: do not reclaim a random zone into another random zone Kyrylo Biryuk
2026-10-13 9:36 ` Damien Le Moal
2026-10-11 17:54 ` [PATCH v3 3/3] dm zoned: keep polling for idle reclaim after a reclaim pass Kyrylo Biryuk
2026-10-13 9:39 ` Damien Le Moal
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=20261011175450.952-1-illofspeed@gmail.com \
--to=illofspeed@gmail.com \
--cc=agk@redhat.com \
--cc=bmarzins@redhat.com \
--cc=dlemoal@kernel.org \
--cc=dm-devel@lists.linux.dev \
--cc=hare@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mpatocka@redhat.com \
--cc=snitzer@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.