[PATCH RFC 0/1] btrfs: don't allocate data off of conventional zones

[PATCH RFC 0/1] btrfs: don't allocate data off of conventional zones

[Johannes Thumshirn]

On a zoned filesystem allocate data block-groups only off of the
sequential zones of a device.

Doing so will free up the conventional zones for the system and metadata
block-groups, eventually removing the need for using the zoned allocator
and all it's required infrastructure, that needs to be emulated, for
conventional zones.

TODO: If the device does not have any sequential zones left, but
conventional, allocate the data block-group from the conventional zone,
or just ENOSPC?

Note: This patchset also is only mildly tested. Several fsx runs for
stressing and file I/O for functional testing, no full fstests run yet.

Johannes Thumshirn (3):
  btrfs: zoned: only allocate data off of sequential zones
  btrfs-progs: collapse find_free_dev_extent into
    find_free_dev_extent_start
  btrfs-progs: zoned: only allocate data off of sequential zones


 fs/btrfs/volumes.c | 30 +++++++++++++++++++-----------
 1 file changed, 19 insertions(+), 11 deletions(-)

-- 
2.52.0

[PATCH RFC 1/1] btrfs: zoned: only allocate data off of sequential zones

[Johannes Thumshirn]

On a zoned filesystem allocate data block-groups only off of the
sequential zones of a device.

Doing so will free up the conventional zones for the system and metadata
block-groups, eventually removing the need for using the zoned allocator
and all it's required infrastructure, that needs to be emulated, for
conventional zones.

Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
---
 fs/btrfs/volumes.c | 30 +++++++++++++++++++-----------
 1 file changed, 19 insertions(+), 11 deletions(-)

diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 6bde24292aeb..0083944649ca 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -1547,7 +1547,7 @@ static u64 dev_extent_search_start(struct btrfs_device *device)
 	}
 }
 
-static bool dev_extent_hole_check_zoned(struct btrfs_device *device,
+static bool dev_extent_hole_check_zoned(struct btrfs_device *device, u64 type,
 					u64 *hole_start, u64 *hole_size,
 					u64 num_bytes)
 {
@@ -1560,6 +1560,8 @@ static bool dev_extent_hole_check_zoned(struct btrfs_device *device,
 	       "hole_start=%llu zone_size=%llu", *hole_start, zone_size);
 
 	while (*hole_size > 0) {
+		bool sequential;
+
 		pos = btrfs_find_allocatable_zones(device, *hole_start,
 						   *hole_start + *hole_size,
 						   num_bytes);
@@ -1571,6 +1573,11 @@ static bool dev_extent_hole_check_zoned(struct btrfs_device *device,
 				break;
 		}
 
+		sequential = btrfs_dev_is_sequential(device, pos);
+
+		if (type & BTRFS_BLOCK_GROUP_DATA && !sequential)
+			goto next_zone;
+
 		ret = btrfs_ensure_empty_zones(device, pos, num_bytes);
 
 		/* Range is ensured to be empty */
@@ -1584,6 +1591,7 @@ static bool dev_extent_hole_check_zoned(struct btrfs_device *device,
 			return true;
 		}
 
+next_zone:
 		*hole_start += zone_size;
 		*hole_size -= zone_size;
 		changed = true;
@@ -1603,8 +1611,8 @@ static bool dev_extent_hole_check_zoned(struct btrfs_device *device,
  * This function may modify @hole_start and @hole_size to reflect the suitable
  * position for allocation. Returns 1 if hole position is updated, 0 otherwise.
  */
-static bool dev_extent_hole_check(struct btrfs_device *device, u64 *hole_start,
-				  u64 *hole_size, u64 num_bytes)
+static bool dev_extent_hole_check(struct btrfs_device *device, u64 type,
+				  u64 *hole_start, u64 *hole_size, u64 num_bytes)
 {
 	bool changed = false;
 	u64 hole_end = *hole_start + *hole_size;
@@ -1630,7 +1638,7 @@ static bool dev_extent_hole_check(struct btrfs_device *device, u64 *hole_start,
 			/* No extra check */
 			break;
 		case BTRFS_CHUNK_ALLOC_ZONED:
-			if (dev_extent_hole_check_zoned(device, hole_start,
+			if (dev_extent_hole_check_zoned(device, type, hole_start,
 							hole_size, num_bytes)) {
 				changed = true;
 				/*
@@ -1675,8 +1683,8 @@ static bool dev_extent_hole_check(struct btrfs_device *device, u64 *hole_start,
  * correct usable device space, as device extent freed in current transaction
  * is not reported as available.
  */
-static int find_free_dev_extent(struct btrfs_device *device, u64 num_bytes,
-				u64 *start, u64 *len)
+static int find_free_dev_extent(struct btrfs_device *device, u64 type,
+				u64 num_bytes, u64 *start, u64 *len)
 {
 	struct btrfs_fs_info *fs_info = device->fs_info;
 	struct btrfs_root *root = fs_info->dev_root;
@@ -1751,8 +1759,8 @@ static int find_free_dev_extent(struct btrfs_device *device, u64 num_bytes,
 
 		if (key.offset > search_start) {
 			hole_size = key.offset - search_start;
-			dev_extent_hole_check(device, &search_start, &hole_size,
-					      num_bytes);
+			dev_extent_hole_check(device, type, &search_start,
+					      &hole_size, num_bytes);
 
 			if (hole_size > max_hole_size) {
 				max_hole_start = search_start;
@@ -1791,7 +1799,7 @@ static int find_free_dev_extent(struct btrfs_device *device, u64 num_bytes,
 	 */
 	if (search_end > search_start) {
 		hole_size = search_end - search_start;
-		if (dev_extent_hole_check(device, &search_start, &hole_size,
+		if (dev_extent_hole_check(device, type, &search_start, &hole_size,
 					  num_bytes)) {
 			btrfs_release_path(path);
 			goto again;
@@ -5243,8 +5251,8 @@ static int gather_device_info(struct btrfs_fs_devices *fs_devices,
 		if (total_avail < ctl->dev_extent_min)
 			continue;
 
-		ret = find_free_dev_extent(device, dev_extent_want, &dev_offset,
-					   &max_avail);
+		ret = find_free_dev_extent(device, ctl->type, dev_extent_want,
+					   &dev_offset, &max_avail);
 		if (ret && ret != -ENOSPC)
 			return ret;
 
-- 
2.52.0

[PATCH RFC 1/2] btrfs-progs: collapse find_free_dev_extent into find_free_dev_extent_start

[Johannes Thumshirn]

Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
---
 kernel-shared/volumes.c | 16 ++++------------
 1 file changed, 4 insertions(+), 12 deletions(-)

diff --git a/kernel-shared/volumes.c b/kernel-shared/volumes.c
index 0a7301281470..f1baf5c30ce0 100644
--- a/kernel-shared/volumes.c
+++ b/kernel-shared/volumes.c
@@ -812,10 +812,9 @@ static bool dev_extent_hole_check(struct btrfs_device *device, u64 *hole_start,
 }
 
 /*
- * find_free_dev_extent_start - find free space in the specified device
+ * find_free_dev_extent - find free space in the specified device
  * @device:	  the device which we search the free space in
  * @num_bytes:	  the size of the free space that we need
- * @search_start: the position from which to begin the search
  * @start:	  store the start of the free space.
  * @len:	  the size of the free space. that we find, or the size
  *		  of the max free space if we don't find suitable free space
@@ -832,9 +831,8 @@ static bool dev_extent_hole_check(struct btrfs_device *device, u64 *hole_start,
  * But if we don't find suitable free space, it is used to store the size of
  * the max free space.
  */
-static int find_free_dev_extent_start(struct btrfs_device *device,
-				      u64 num_bytes, u64 search_start,
-				      u64 *start, u64 *len)
+static int find_free_dev_extent(struct btrfs_device *device,
+			        u64 num_bytes, u64 *start, u64 *len)
 {
 	struct btrfs_key key;
 	struct btrfs_root *root = device->dev_root;
@@ -849,6 +847,7 @@ static int find_free_dev_extent_start(struct btrfs_device *device,
 	int slot;
 	struct extent_buffer *l;
 	u64 zone_size = 0;
+	u64 search_start = 0;
 
 	if (device->zone_info)
 		zone_size = device->zone_info->zone_size;
@@ -975,13 +974,6 @@ out:
 	return ret;
 }
 
-static int find_free_dev_extent(struct btrfs_device *device, u64 num_bytes,
-				u64 *start, u64 *len)
-{
-	/* FIXME use last free of some kind */
-	return find_free_dev_extent_start(device, num_bytes, 0, start, len);
-}
-
 /*
  * Insert one device extent into the fs.
  */
-- 
2.52.0

[PATCH RFC 2/2] btrfs-progs: zoned: only allocate data off of sequential zones

[Johannes Thumshirn]

On a zoned filesystem allocatate data block-groups only off of sequential
zones leaving conventional zones to metadata and system block-groups.

TODO if the device doesn't implement conventional zones or does not have
any empty conventional zones left, skip this step and allow metadata and
system block-groups on sequential zones.

Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
---
 kernel-shared/volumes.c | 59 ++++++++++++++++++++++++++---------------
 1 file changed, 38 insertions(+), 21 deletions(-)

diff --git a/kernel-shared/volumes.c b/kernel-shared/volumes.c
index f1baf5c30ce0..fcf6b40a2d4a 100644
--- a/kernel-shared/volumes.c
+++ b/kernel-shared/volumes.c
@@ -763,23 +763,39 @@ static u64 dev_extent_search_start(struct btrfs_device *device, u64 start)
 	}
 }
 
-static bool dev_extent_hole_check_zoned(struct btrfs_device *device,
+static bool dev_extent_hole_check_zoned(struct btrfs_device *device, u64 type,
 					u64 *hole_start, u64 *hole_size,
 					u64 num_bytes)
 {
-	u64 pos;
+	u64 zone_size = device->zone_info->zone_size;
+	bool changed = false;
 
 	ASSERT(IS_ALIGNED(*hole_start, device->zone_info->zone_size));
 
-	pos = btrfs_find_allocatable_zones(device, *hole_start,
-					   *hole_start + *hole_size, num_bytes);
-	if (pos != *hole_start) {
-		*hole_size = *hole_start + *hole_size - pos;
-		*hole_start = pos;
-		return true;
-	}
+	while (*hole_size > 0) {
+		bool sequential;
+		u64 pos;
 
-	return false;
+		pos = btrfs_find_allocatable_zones(device, *hole_start,
+				*hole_start + *hole_size, num_bytes);
+		if (pos != *hole_start) {
+			*hole_size = *hole_start + *hole_size - pos;
+			*hole_start = pos;
+			return true;
+		}
+
+		sequential = btrfs_dev_is_sequential(device, pos);
+		if (type & BTRFS_BLOCK_GROUP_DATA && sequential)
+			return false;
+
+		if (!(type & BTRFS_BLOCK_GROUP_DATA) && !sequential)
+			return false;
+
+		*hole_start += zone_size;
+		*hole_size -= zone_size;
+		changed = true;
+	}
+	return changed;
 }
 
 /**
@@ -794,15 +810,15 @@ static bool dev_extent_hole_check_zoned(struct btrfs_device *device,
  * position for allocation. Returns true if hole position is updated, false
  * otherwise.
  */
-static bool dev_extent_hole_check(struct btrfs_device *device, u64 *hole_start,
-				  u64 *hole_size, u64 num_bytes)
+static bool dev_extent_hole_check(struct btrfs_device *device, u64 type,
+				  u64 *hole_start, u64 *hole_size, u64 num_bytes)
 {
 	switch (device->fs_devices->chunk_alloc_policy) {
 	case BTRFS_CHUNK_ALLOC_REGULAR:
 		/* No check */
 		break;
 	case BTRFS_CHUNK_ALLOC_ZONED:
-		return dev_extent_hole_check_zoned(device, hole_start,
+		return dev_extent_hole_check_zoned(device, type, hole_start,
 						   hole_size, num_bytes);
 	default:
 		BUG();
@@ -814,6 +830,7 @@ static bool dev_extent_hole_check(struct btrfs_device *device, u64 *hole_start,
 /*
  * find_free_dev_extent - find free space in the specified device
  * @device:	  the device which we search the free space in
+ * @type:         the block_group type we want to allocate
  * @num_bytes:	  the size of the free space that we need
  * @start:	  store the start of the free space.
  * @len:	  the size of the free space. that we find, or the size
@@ -831,7 +848,7 @@ static bool dev_extent_hole_check(struct btrfs_device *device, u64 *hole_start,
  * But if we don't find suitable free space, it is used to store the size of
  * the max free space.
  */
-static int find_free_dev_extent(struct btrfs_device *device,
+static int find_free_dev_extent(struct btrfs_device *device, u64 type,
 			        u64 num_bytes, u64 *start, u64 *len)
 {
 	struct btrfs_key key;
@@ -907,7 +924,7 @@ again:
 
 		if (key.offset > search_start) {
 			hole_size = key.offset - search_start;
-			dev_extent_hole_check(device, &search_start, &hole_size,
+			dev_extent_hole_check(device, type, &search_start, &hole_size,
 					      num_bytes);
 
 			if (hole_size > max_hole_size) {
@@ -947,8 +964,8 @@ next:
 	 */
 	if (search_end > search_start) {
 		hole_size = search_end - search_start;
-		if (dev_extent_hole_check(device, &search_start, &hole_size,
-					  num_bytes)) {
+		if (dev_extent_hole_check(device, type, &search_start,
+					  &hole_size, num_bytes)) {
 			btrfs_release_path(path);
 			goto again;
 		}
@@ -1028,12 +1045,12 @@ err:
  * Allocate one free dev extent and insert it into the fs.
  */
 static int btrfs_alloc_dev_extent(struct btrfs_trans_handle *trans,
-				  struct btrfs_device *device,
+				  struct btrfs_device *device, u64 type,
 				  u64 chunk_offset, u64 num_bytes, u64 *start)
 {
 	int ret;
 
-	ret = find_free_dev_extent(device, num_bytes, start, NULL);
+	ret = find_free_dev_extent(device, type, num_bytes, start, NULL);
 	if (ret)
 		return ret;
 	return btrfs_insert_dev_extent(trans, device, chunk_offset, num_bytes,
@@ -1598,8 +1615,8 @@ static int create_chunk(struct btrfs_trans_handle *trans,
 			list_move(&device->dev_list, dev_list);
 
 		if (!ctl->dev_offset) {
-			ret = btrfs_alloc_dev_extent(trans, device, key.offset,
-					ctl->stripe_size, &dev_offset);
+			ret = btrfs_alloc_dev_extent(trans, device, ctl->type,
+					key.offset, ctl->stripe_size, &dev_offset);
 			if (ret < 0)
 				goto out_chunk_map;
 		} else {
-- 
2.52.0

Re: [PATCH RFC 0/1] btrfs: don't allocate data off of conventional zones

[Christoph Hellwig]

On Fri, Jan 16, 2026 at 10:57:36AM +0100, Johannes Thumshirn wrote:
> On a zoned filesystem allocate data block-groups only off of the
> sequential zones of a device.
> 
> Doing so will free up the conventional zones for the system and metadata
> block-groups, eventually removing the need for using the zoned allocator
> and all it's required infrastructure, that needs to be emulated, for
> conventional zones.
> 
> TODO: If the device does not have any sequential zones left, but
> conventional, allocate the data block-group from the conventional zone,
> or just ENOSPC?

How likely is that?  Given that amount of metadata btrfs has I'd be
more worried about the inverse: running out of conventional zones for
metadata.  Did you or anyone do a rough calculation of how much
metadata you need relative to the data for various scenarios (small
files, large files, lots of snapshots, etc)?

Keeping the pools entirely separate is of course much easier, but it
has to work out, and having allowed to combined them before might
have set expectations as well unfortunately.

Re: [PATCH RFC 0/1] btrfs: don't allocate data off of conventional zones

[Johannes Thumshirn]

On 1/16/26 3:54 PM, Christoph Hellwig wrote:
> On Fri, Jan 16, 2026 at 10:57:36AM +0100, Johannes Thumshirn wrote:
>> On a zoned filesystem allocate data block-groups only off of the
>> sequential zones of a device.
>>
>> Doing so will free up the conventional zones for the system and metadata
>> block-groups, eventually removing the need for using the zoned allocator
>> and all it's required infrastructure, that needs to be emulated, for
>> conventional zones.
>>
>> TODO: If the device does not have any sequential zones left, but
>> conventional, allocate the data block-group from the conventional zone,
>> or just ENOSPC?
> How likely is that?  Given that amount of metadata btrfs has I'd be
> more worried about the inverse: running out of conventional zones for
> metadata.  Did you or anyone do a rough calculation of how much
> metadata you need relative to the data for various scenarios (small
> files, large files, lots of snapshots, etc)?

Yes I did have the inverse of this patchset as well, but I think we 
should still be able to allocate metadata on sequential zones. Which is 
needed for ZNS support anyways.

> Keeping the pools entirely separate is of course much easier, but it
> has to work out, and having allowed to combined them before might
> have set expectations as well unfortunately.

The main intention behind this is, that we can handle metadata like 
metadata on regular non zoned devices, including the ability to 
overwrite it. But agreed I'd need to measure how much space we save this 
way. The second motivation is that we can remove the faking of 
sequential zones on conventional zones, aka the write pointer emulation 
etc..

Re: [PATCH RFC 0/1] btrfs: don't allocate data off of conventional zones

[Johannes Thumshirn]

On 1/16/26 7:46 PM, Johannes Thumshirn wrote:
> On 1/16/26 3:54 PM, Christoph Hellwig wrote:
>> On Fri, Jan 16, 2026 at 10:57:36AM +0100, Johannes Thumshirn wrote:
>>> On a zoned filesystem allocate data block-groups only off of the
>>> sequential zones of a device.
>>>
>>> Doing so will free up the conventional zones for the system and metadata
>>> block-groups, eventually removing the need for using the zoned allocator
>>> and all it's required infrastructure, that needs to be emulated, for
>>> conventional zones.
>>>
>>> TODO: If the device does not have any sequential zones left, but
>>> conventional, allocate the data block-group from the conventional zone,
>>> or just ENOSPC?
>> How likely is that?  Given that amount of metadata btrfs has I'd be
>> more worried about the inverse: running out of conventional zones for
>> metadata.  Did you or anyone do a rough calculation of how much
>> metadata you need relative to the data for various scenarios (small
>> files, large files, lots of snapshots, etc)?
> Yes I did have the inverse of this patchset as well, but I think we
> should still be able to allocate metadata on sequential zones. Which is
> needed for ZNS support anyways.
>
>> Keeping the pools entirely separate is of course much easier, but it
>> has to work out, and having allowed to combined them before might
>> have set expectations as well unfortunately.
> The main intention behind this is, that we can handle metadata like
> metadata on regular non zoned devices, including the ability to
> overwrite it. But agreed I'd need to measure how much space we save this
> way. The second motivation is that we can remove the faking of
> sequential zones on conventional zones, aka the write pointer emulation
> etc..
One thing we could do here (and it shouldn't be easy as well) is, 
*prefer* sequential zones for data and conventional zones for metadata. 
For sequential zones we already have a bitmap, for conventional we can 
trivially create one and then as long as there's still available zones 
in each of them distribute the data that way.

Re: [PATCH RFC 0/1] btrfs: don't allocate data off of conventional zones

[hch]

On Sat, Jan 17, 2026 at 09:46:49AM +0000, Johannes Thumshirn wrote:
> > The main intention behind this is, that we can handle metadata like
> > metadata on regular non zoned devices, including the ability to
> > overwrite it. But agreed I'd need to measure how much space we save this
> > way. The second motivation is that we can remove the faking of
> > sequential zones on conventional zones, aka the write pointer emulation
> > etc..
> One thing we could do here (and it shouldn't be easy as well) is, 
> *prefer* sequential zones for data and conventional zones for metadata. 

Absolutely.

Re: [PATCH RFC 0/1] btrfs: don't allocate data off of conventional zones

[hch]

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).