From: Johannes Thumshirn <Johannes.Thumshirn@wdc.com>
To: Naohiro Aota <Naohiro.Aota@wdc.com>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH v2 12/12] btrfs-progs: zoned: fix alloc_offset calculation for partly conventional block groups
Date: Wed, 19 Feb 2025 16:58:02 +0000 [thread overview]
Message-ID: <64e99dfc-e2d3-45a4-9216-ff9cd8aa7d7a@wdc.com> (raw)
In-Reply-To: <c6a9d1c664cf8595ac6a2a8acf458cf46c7cce8d.1739951758.git.naohiro.aota@wdc.com>
On 19.02.25 09:00, Naohiro Aota wrote:
> When one of two zones composing a DUP block group is a conventional zone, we
> have the zone_info[i]->alloc_offset = WP_CONVENTIONAL. That will, of course,
> not match the write pointer of the other zone, and fails that block group.
>
> This commit solves that issue by properly recovering the emulated write pointer
> from the last allocated extent. The offset for the SINGLE, DUP, and RAID1 are
> straight-forward: it is same as the end of last allocated extent. The RAID0 and
> RAID10 are a bit tricky that we need to do the math of striping.
I wonder if we need this patch on the kernel side as well. Can happen
there too.
next prev parent reply other threads:[~2025-02-19 16:58 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-19 7:57 [PATCH v2 00/12] btrfs-progs: zoned: support zone capacity and Naohiro Aota
2025-02-19 7:57 ` [PATCH v2 01/12] btrfs-progs: introduce min_not_zero() Naohiro Aota
2025-02-19 7:57 ` [PATCH v2 02/12] btrfs-progs: zoned: introduce a zone_info struct in btrfs_load_block_group_zone_info Naohiro Aota
2025-02-19 7:57 ` [PATCH v2 03/12] btrfs-progs: zoned: support zone capacity Naohiro Aota
2025-02-19 7:57 ` [PATCH v2 04/12] btrfs-progs: zoned: load zone activeness Naohiro Aota
2025-02-19 7:57 ` [PATCH v2 05/12] btrfs-progs: zoned: activate block group on loading Naohiro Aota
2025-02-19 7:57 ` [PATCH v2 06/12] btrfs-progs: factor out btrfs_load_zone_info() Naohiro Aota
2025-02-19 7:57 ` [PATCH v2 07/12] btrfs-progs: zoned: factor out SINGLE zone info loading Naohiro Aota
2025-02-19 7:57 ` [PATCH v2 08/12] btrfs-progs: zoned: implement DUP " Naohiro Aota
2025-02-19 7:57 ` [PATCH v2 09/12] btrfs-progs: zoned: implement RAID1 " Naohiro Aota
2025-02-19 7:57 ` [PATCH v2 10/12] btrfs-progs: zoned: implement RAID0 " Naohiro Aota
2025-02-19 7:57 ` [PATCH v2 11/12] btrfs-progs: implement RAID10 " Naohiro Aota
2025-02-19 7:57 ` [PATCH v2 12/12] btrfs-progs: zoned: fix alloc_offset calculation for partly conventional block groups Naohiro Aota
2025-02-19 16:58 ` Johannes Thumshirn [this message]
2025-02-20 5:06 ` Naohiro Aota
2025-02-19 16:58 ` [PATCH v2 00/12] btrfs-progs: zoned: support zone capacity and Johannes Thumshirn
2025-03-05 13:20 ` David Sterba
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=64e99dfc-e2d3-45a4-9216-ff9cd8aa7d7a@wdc.com \
--to=johannes.thumshirn@wdc.com \
--cc=Naohiro.Aota@wdc.com \
--cc=linux-btrfs@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox