Re: [PATCH v4 2/4] qcow2: add configurations for zoned format extension

[Sam Li]

Hello Eric,

Eric Blake <eblake@redhat.com> 于2023年9月28日周四 23:15写道：
>
> On Mon, Sep 18, 2023 at 05:53:11PM +0800, Sam Li wrote:
> > To configure the zoned format feature on the qcow2 driver, it
> > requires settings as: the device size, zone model, zone size,
> > zone capacity, number of conventional zones, limits on zone
> > resources (max append sectors, max open zones, and max_active_zones).
> >
> > To create a qcow2 file with zoned format, use command like this:
> > $ qemu-img create -f qcow2 test.qcow2 -o size=768M -o
> > zone_size=64M -o zone_capacity=64M -o nr_conv_zones=0 -o
> > max_append_sectors=512 -o max_open_zones=0 -o max_active_zones=0
> > -o zone_model=1
> >
> > Signed-off-by: Sam Li <faithilikerun@gmail.com>
> > ---
> >  block/qcow2.c                    | 186 ++++++++++++++++++++++++++++++-
> >  block/qcow2.h                    |  28 +++++
> >  docs/interop/qcow2.txt           |  36 ++++++
> >  include/block/block_int-common.h |  13 +++
> >  qapi/block-core.json             |  30 ++++-
> >  5 files changed, 291 insertions(+), 2 deletions(-)
>
> Below, I'll focus only on the spec change, not the implementation:
>
> >
> > diff --git a/block/qcow2.c b/block/qcow2.c
> > index b48cd9ce63..521276fc51 100644
> > --- a/block/qcow2.c
> > +++ b/block/qcow2.c
> > @@ -73,6 +73,7 @@ typedef struct {
> >  #define  QCOW2_EXT_MAGIC_CRYPTO_HEADER 0x0537be77
> >  #define  QCOW2_EXT_MAGIC_BITMAPS 0x23852875
> >  #define  QCOW2_EXT_MAGIC_DATA_FILE 0x44415441
> > +#define  QCOW2_EXT_MAGIC_ZONED_FORMAT 0x7a6264
>
> Why not spell it 0x007a6264 with 8 hex digits, like the others?  (I
> get why you choose that constant, though - ascii 'zbd')
>
> > +++ b/docs/interop/qcow2.txt
> > @@ -331,6 +331,42 @@ The fields of the bitmaps extension are:
> >                     Offset into the image file at which the bitmap directory
> >                     starts. Must be aligned to a cluster boundary.
> >
> > +== Zoned extension ==
>
> Where is the magic number for this extension called out?  That's
> missing, and MUST be part of the spec.

It's a part of the header extension type in the spec. I will add it.

>
> Back-compatibility constraints: you should consider what happens in
> both of the following cases:
>
> a program that intends to do read-only access to the qcow2 file but
> which does not understand this extension header (for example, an older
> version of 'qemu-img convert' being used to extract data from a newer
> .qcow2 file with this header present - but also the new 'nbdkit
> qcow2dec' decoder plugin just released in nbdkit 1.36).  Is it safe to
> read the data as-is, by basically ignoring zone informations?  Or will
> that ever produce wrong data (for example, if operations on a
> particular zone imply that the guest should read all zeroes after the
> current zone offset within that zone, regardless of whether non-zero
> content was previously stored at those offsets - then not honoring the
> existence of the extension header would require you to add and
> document an incompatible feature bit so that reader apps fail to open
> the file rather than reading wrong data).
>
> a program that intends to edit the qcow2 file but which does not
> understand this extension header (again, consider access by an older
> version of qemu).  Is it safe to just write data anywhere in the disk,
> but where failure to update the zone metadata means that all
> subsequent use of the file MUST behave as if it is now a non-zeoned
> device?  If so, then it is sufficient to document an autoclear feature
> bit: any time a newer qcow2 writer creates a file with a zoned
> extension, it also sets the autoclear feature bit; any time an older
> qcow2 writer edits a file with the autoclear bit, it clears the bit
> (because it has no idea if its edits invalidated the unknown
> extension).  Then when the new qcow2 program again accesses the file,
> it knows that the zone information is no longer reliable, and can fall
> back to forcing the image to behave as flat.

Considering access by an older version of qemu ('old qemu' for abbr.)
with a qcow2 file created with zoned extension ('new file' for abbr.),
reads from a new file on old qemu which does not understand zoned
information are safe. The zoned extension represents necessary zone
states for all zones, which puts constraints to operations on the
zones. For example, writes to offsets that are over the capacity of
that zone are not allowed, where it will be read as zeroes. The old
qemu ignores that and reads the new file as a regular one anyway.

However, what is unsafe is when an old qemu program gets involved in
editing a new file. The new qemu will not see the write pointer
changes of the new file that was done sometime by old qemu programs.
Then the zone information is no longer reliable as you illustrated.

Therefore I will add an autoclear bit for the latter case. It clears
the zoned extension when it is set by old qemu programs.

>
> > +
> > +The zoned extension is an optional header extension. It contains fields for
> > +emulating the zoned stroage model (https://zonedstorage.io/).
>
> Assuming that you'll need to add one or two feature bits (most likely
> an autoclear bit, to prevent editing the file without keeping the zone
> information up-to-data, and possibly also an incompatible feature bit,
> if interpreting the file even without editing it is impossible without
> understanding zones), you'll want to mention this header's relation to
> those feature bit(s).
>
> > +
> > +The fields of the zoned extension are:
> > +    Byte        0:  zoned
> > +                    Zoned model, 1 for host-managed and 0 for non-zoned 
> > devices.
>
> This tells me nothing about what those two models mean.  You'll need
> to describe them better for an independent implementation of a qcow2
> reader (such as 'nbdkit qcow2dec') to be able to properly read such a
> file with either value, even if it doesn't plan on editing it.
>
> If we do add feature bits, what happens when reading a file when the
> feature bits are set but this extension header is missing?

It's not allowed to set the zone model to host-managed type without
other extension header fields like zone size.

>
> > +
> > +            1 - 3:  Reserved, must be zero.
> > +
> > +            4 - 7:  zone_size
> > +                    Total number of logical blocks within the zones in 
> > bytes.
>
> This is confusing.  It is a number of blocks, or a number of bytes?  I
> would prefer bytes (will we ever have to worry about a device that can
> have zones larger than 4G - then make this 8 bytes instead of 4, and
> see comments below about alignment), but then word it as:
>
> Total size of each zone, in bytes.
>
> Also, should you require that the zone_size be a multiple of the
> cluster size and/or a power of 2?  (That is, if I have a qcow2 file
> with 2M clusters, does it make sense to permit a zone size of only 1M,
> or should zone size always be at least as large as a cluster?)

In general the zone size must be a power of two. It is not related to
the cluster size.

>
> > +
> > +           8 - 11:  zone_capacity
> > +                    The number of writable logical blocks within the zones 
> > in
> > +                    bytes. A zone capacity is always smaller or equal to 
> > the
> > +                    zone size.
>
> Again, mixing the term blocks and bytes in the same sentence is confusing.
>
> > +
> > +          12 - 15:  nr_conv_zones
> > +                    The number of conventional zones.
> > +
> > +          16 - 19:  nr_zones
> > +                    The number of zones.
>
> What's the difference between these two numbers?

nr_zone = conventional_zones + sequential_zones.

>
> > +
> > +          20 - 23:  max_active_zones
> > +                    The limit of the zones that have the implicit open,
> > +                    explicit open or closed state.
> > +
> > +          24 - 27:  max_open_zones
> > +                    The maximal allowed open zones.
> > +
> > +          28 - 35:  max_append_sectors
> > +                    The maximal number of 512-byte sectors of a zone
> > +                    append request that can be issued to the device.
>
> Is this value in sectors instead of bytes?  I'd prefer bytes, but then
> document that the value must be a multiple of 512.  Also, having a
> 64-bit number not be 64-bit aligned within the extension header is
> unwise.  Please rearrange fields so that all 64-bit fields are 8-byte
> aligned.
>
> This structure as written has implicit tail padding (all extension
> headers must be 8-byte multiples in the end; but the spec already
> documents how that is handled).  Is it worth explicitly calling out
> tail padding up to an 8-byte boundary?

I see. I will rearrange it to 8-byte alignment.

Thanks for your comments!

>
> > +
> >  == Full disk encryption header pointer ==
> >
> >  The full disk encryption header must be present if, and only if, the
> > diff --git a/include/block/block_int-common.h 
> > b/include/block/block_int-common.h
> > index 85be256c09..d169d15dd6 100644
> > --- a/include/block/block_int-common.h
>
> --
> Eric Blake, Principal Software Engineer
> Red Hat, Inc.
> Virtualization:  qemu.org | libguestfs.org
>