mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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.

      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®