Re: [RFC] btrfs: zoned: reset stale zones in unallocated device space
From: Johannes Thumshirn
Date: Tue Oct 27 2026 - 11:26:44 EST
On 10/27/26 3:48 PM, Марк Коренберг wrote:
Hi Johannes,Feel free to take over the patch, I have enough patches in flight atm that I need to get in, so one less on the plate is fine for me.
I rebased your patch onto current master and found a few problems in
review, so I reworked it. v2 is attached. Main issues:
1) Data loss during device replace: the replace target has no chunk
stripes until the replace finishes, so all data already copied to
it was reset, and the resumed replace never copies it again.
Trigger: start a replace, umount or remount,ro, then mount rw.
v2 skips the pass while a replace is ongoing.
2) Races: chunks can be allocated (data reloc bg, transaction kthread)
and removed (relocating repair after a read error) while the pass
runs, and the removal is not committed yet. v2 takes
reclaim_bgs_lock, commits, and holds chunk_mutex.
3) Used zones: v1 marked only the zone where each stripe starts. Today
stripes are exactly one zone long, but mount does not enforce that,
so a longer stripe would get its other zones reset. v2 checks
device->alloc_state instead, the allocator's own record of which
ranges belong to chunks, over the full stripe length. This also
drops the bitmap allocation that could fail the mount.
4) Zones that must not be reset: zones beyond total_bytes, read-only
devices, offline and read-only zones. v2 skips them.
5) v2 resets adjacent zones in one call and logs each reset range.
The commit message also now says why the existing code does not help:
btrfs_find_allocatable_zones() skips non-empty zones, so leaked zones
are never reused. And the typo in your Signed-off-by is fixed.
I used an AI assistant (Claude) for the review and for v2. v2 is build
tested and checkpatch clean, not runtime tested yet.
Please check that it still covers the case you hit, and tell me if you
prefer to fold it into your patch or keep it as a fix on top.