Re: [PATCH v14 0/6] Add full zoned storage emulation to the qcow2 driver

On Thu, Jul 09, 2026 at 12:16:09AM +0200, Sam Li wrote:
> This patch series add a new extension - zoned format - to the
> qcow2 driver, allowing full zoned storage emulation on a qcow2
> image file. A user can attach such an image to a guest and have
> it appear as a host-managed zoned block device.
> 
> The zoned format is opt-in through a new qcow2 header extension
> that pins the zone geometry. Behind the extension is a dedicated
> zoned metadata region that stores one 8-byte write pointer (WP)
> per zone. The extension is gated by an incompatible bit, so an
> older qcow2 implementation cannot accidentally open the image.
> 
> Each write pointer is routed through the write pointer cache,
> a Qcow2Cache object. The write pointer cache is written to disk
> after the qcow2 metadata is written, thus guaranteeing that
> the write pointer is updated after the corresponding data is
> written.
> 
> Zone states are in memory. Read-only and offline states are
> device-internal events, which are not modelled in qcow2
> emulation for simplicity. The other zone states
> (closed, empty, full) can be inferred from write poiner
> values, presistent across QEMU reboots. The open states are
> kept in memory using open zone lists.
> 

Hello Sam,


I ran: fio test suite, zonefs test suite, blktests, and zbd-state-test
(WD internal test suite), on the following backends:

1) QEMU qcow2 (this series):
$ lsblk -z
NAME ZONED        ZONE-SZ ZONE-NR ZONE-AMAX ZONE-OMAX ZONE-APP ZONE-WGRAN
vda  host-managed    256M     140         0        16       4K       512B

2) zloop:
https://docs.kernel.org/admin-guide/blockdev/zoned_loop.html
$ lsblk -z
NAME ZONED        ZONE-SZ ZONE-NR ZONE-AMAX ZONE-OMAX ZONE-APP ZONE-WGRAN
vda  host-managed    256M     140         0        16       1M         4K

3) A real HM-SMR device:
$ lsblk -z
NAME ZONED        ZONE-SZ ZONE-NR ZONE-AMAX ZONE-OMAX ZONE-APP ZONE-WGRAN
sda  host-managed    256M  111760         0       128      32M         4K




fio test suite: looks good.

zonefs test suite: looks good.

blktests: same amount of test cases pass.
Only major difference I can see is for the following test cases:

QEMU qcow2:
zbd/004 => vda (write split across sequential zones)         [passed]
    runtime    ...  148.769s


zloop:
zbd/004 => vda (write split across sequential zones)         [passed]
    runtime    ...  47.446s


real dev:
zbd/004 => sda (write split across sequential zones)         [passed]
    runtime    ...  27.616s


QEMU qcow2 seems significantly slower than zloop for this test case.

Perhaps not something to worry about, but the difference compared to
zloop is big enough to raise my eyebrows :)


zbd-state-test:
Show a test case for QEMU qcow2 that fails, but passes on zloop and a
real device.

You can use e.g. blkzone
or libzbd:
https://github.com/westerndigitalcorporation/libzbd
to perform zone operations.

I guess you could also use iotests for this test case.

021: OPEN_ZONE full to full... [Failed]
	    => Expected zone condition fu
	       Got oe

Test case seem to do:
1) Finds a zone in zone state empty.
2) Fills the zone (using dd), zone is now in zone state full.
3) Tries to explicitly open the zone (this zone transition is not legal),
   and the open command should fail.
4) Checks the zone state of the zone, should still be zone state full.

I guess the problem with the QEMU qcow2 code is that it actually changes
the zone state to explicit open in step 3), while it should fail the open
command and keep the zone in zone state full.

If you look at e.g. null_blk: null_open_zone(), it also fails to open a
full zone.


Kind regards,
Niklas