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

On Fri, Aug 7, 2026 at 1:31 PM Niklas Cassel <[email protected]> wrote:
>
> 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 :)

Hi Niklas,

Thanks for running the tests and sharing your thoughts. A possible
reason for QEMU qcow being way slower than zloop might be the write
dependency of writes (qcow2 metadata, zoned metadata, data) for crash
consistency. I'll look into it to see the real problem behind this
when I have some free time.

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

Ah, right. That’s a state transition I missed. Thanks for catching that.

Best regards,
Sam