From: hch <hch@lst.de>
To: Johannes Thumshirn <Johannes.Thumshirn@wdc.com>
Cc: hch <hch@lst.de>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
Damien Le Moal <dlemoal@kernel.org>,
Naohiro Aota <Naohiro.Aota@wdc.com>,
Hans Holmberg <Hans.Holmberg@wdc.com>,
David Sterba <dsterba@suse.com>, WenRuo Qu <wqu@suse.com>
Subject: Re: [PATCH RFC 0/1] btrfs: don't allocate data off of conventional zones
Date: Mon, 19 Jan 2026 07:50:57 +0100 [thread overview]
Message-ID: <20260119065057.GB1316@lst.de> (raw)
In-Reply-To: <9a37829c-cc94-4d4a-b732-834e1c68cc2c@wdc.com>
On Fri, Jan 16, 2026 at 06:46:23PM +0000, Johannes Thumshirn wrote:
> way. The second motivation is that we can remove the faking of
> sequential zones on conventional zones, aka the write pointer emulation
> etc..
Is that so much code? For XFS, it basically is a making the replacement
of REQ_OP_WRITE with REQ_OP_ZONE_APPEND in the lowest level write path
conditional instead of unconditional, and to query the rmap to fake up
a write pointer at mount time. At the same time this allows running
on conventional devices, which is not just great for testing, but also
allows direct benchmarking of the different allocators (and it turns out
there's plenty workloads where at least on XFS the zoned allocator
does better).
prev parent reply other threads:[~2026-01-19 6:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-16 9:57 [PATCH RFC 0/1] btrfs: don't allocate data off of conventional zones Johannes Thumshirn
2026-01-16 9:57 ` [PATCH RFC 1/1] btrfs: zoned: only allocate data off of sequential zones Johannes Thumshirn
2026-01-16 9:57 ` [PATCH RFC 1/2] btrfs-progs: collapse find_free_dev_extent into find_free_dev_extent_start Johannes Thumshirn
2026-01-16 9:57 ` [PATCH RFC 2/2] btrfs-progs: zoned: only allocate data off of sequential zones Johannes Thumshirn
2026-01-16 14:54 ` [PATCH RFC 0/1] btrfs: don't allocate data off of conventional zones Christoph Hellwig
2026-01-16 18:46 ` Johannes Thumshirn
2026-01-17 9:46 ` Johannes Thumshirn
2026-01-19 6:48 ` hch
2026-01-19 6:50 ` hch [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=20260119065057.GB1316@lst.de \
--to=hch@lst.de \
--cc=Hans.Holmberg@wdc.com \
--cc=Johannes.Thumshirn@wdc.com \
--cc=Naohiro.Aota@wdc.com \
--cc=dlemoal@kernel.org \
--cc=dsterba@suse.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=wqu@suse.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