From: Johannes Thumshirn <johannes.thumshirn@wdc.com>
To: "Марк Коренберг" <socketpair@gmail.com>
Cc: David Sterba <dsterba@suse.com>, Chris Mason <mason@kernel.org>,
linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC] btrfs: zoned: reset stale zones in unallocated device space
Date: Tue, 27 Oct 2026 16:05:58 +0100 [thread overview]
Message-ID: <ba9e4a81-6959-4ed2-aed3-123aee594dff@wdc.com> (raw)
In-Reply-To: <CAEmTpZGifFxr+yaKddZcG8UxhntYvZROygi6s-8goAoxuUzqHQ@mail.gmail.com>
On 10/27/26 3:48 PM, Марк Коренберг wrote:
> Hi Johannes,
>
> 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.
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.
prev parent reply other threads:[~2026-10-27 15:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-27 8:36 Марк Коренберг
2026-10-27 10:27 ` Johannes Thumshirn
2026-10-27 14:48 ` Марк Коренберг
2026-10-27 15:05 ` Johannes Thumshirn [this message]
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=ba9e4a81-6959-4ed2-aed3-123aee594dff@wdc.com \
--to=johannes.thumshirn@wdc.com \
--cc=dsterba@suse.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mason@kernel.org \
--cc=socketpair@gmail.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
all inboxes | Powered by JetHome®