Re: [PATCH v4 2/4] qcow2: add configurations for zoned format extension
Hello Eric,
Eric Blake 于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
> > ---
> > 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
> >
Re: [PATCH v4 2/4] qcow2: add configurations for zoned format extension
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
> ---
> 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.
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.
> +
> +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:
> +Byte0: 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?
> +
> +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
Re: [PATCH v4 2/4] qcow2: add configurations for zoned format extension
Markus Armbruster 于2023年9月25日周一 21:05写道：
>
> Sam Li writes:
>
> > 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
>
> [...]
>
> > diff --git a/qapi/block-core.json b/qapi/block-core.json
> > index 2b1d493d6e..2aad82c399 100644
> > --- a/qapi/block-core.json
> > +++ b/qapi/block-core.json
> > @@ -5021,6 +5021,27 @@
> > # @compression-type: The image cluster compression method
> > # (default: zlib, since 5.1)
> > #
> > +# @zone-model: Zoned device model, 1 for host-managed and 0 for
> > +# non-zoned devices (default: 0, since 8.2)
>
> Shouldn't this be a QAPI enum rather than a number?
>
> > +#
> > +# @zone-size: Total number of logical blocks within zones in bytes
> > +# (since 8.2)
> > +#
> > +# @zone-capacity: The number of usable logical blocks within zones
> > +# in bytes. A zone capacity is always smaller or equal to the
> > +# zone size. (since 8.2)
> > +#
> > +# @nr-conv-zones: The number of conventional zones of the zoned device
> > +# (since 8.2)
>
> I still think @conventional-zones would be more obvious.
>
> > +#
> > +# @max-open-zones: The maximal number of open zones (since 8.2)
> > +#
> > +# @max-active-zones: The limit of the zones that have the implicit
> > +# open, explicit open or closed state (since 8.2)
>
> Maybe "The maximum number of zones in the implicit open, explicit open
> or closed state".
>
> (I'll repeat suggestions until you reject them, just to make sure they
> get ignored by accident)
Thanks for noticing. I will change them (enum, conv, maz) in v5.
>
> > +#
> > +# @max-append-sectors: The maximal number of 512-byte sectors of a zone
> > +# append request that can be issued to the device. (since 8.2)
> > +#
> > # Since: 2.12
> > ##
> > { 'struct': 'BlockdevCreateOptionsQcow2',
> > @@ -5037,7 +5058,14 @@
> > '*preallocation': 'PreallocMode',
> > '*lazy-refcounts': 'bool',
> > '*refcount-bits': 'int',
> > -'*compression-type':'Qcow2CompressionType' } }
> > +'*compression-type':'Qcow2CompressionType',
> > +'*zone-model': 'uint8',
> > +'*zone-size': 'size',
> > +'*zone-capacity': 'size',
> > +'*nr-conv-zones': 'uint32',
> > +'*max-open-zones': 'uint32',
> > +'*max-active-zones': 'uint32',
> > +'*max-append-sectors': 'uint32' } }
> >
> > ##
> > # @BlockdevCreateOptionsQed:
>
Re: [PATCH v4 2/4] qcow2: add configurations for zoned format extension
Sam Li writes:
> 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
[...]
> diff --git a/qapi/block-core.json b/qapi/block-core.json
> index 2b1d493d6e..2aad82c399 100644
> --- a/qapi/block-core.json
> +++ b/qapi/block-core.json
> @@ -5021,6 +5021,27 @@
> # @compression-type: The image cluster compression method
> # (default: zlib, since 5.1)
> #
> +# @zone-model: Zoned device model, 1 for host-managed and 0 for
> +# non-zoned devices (default: 0, since 8.2)
Shouldn't this be a QAPI enum rather than a number?
> +#
> +# @zone-size: Total number of logical blocks within zones in bytes
> +# (since 8.2)
> +#
> +# @zone-capacity: The number of usable logical blocks within zones
> +# in bytes. A zone capacity is always smaller or equal to the
> +# zone size. (since 8.2)
> +#
> +# @nr-conv-zones: The number of conventional zones of the zoned device
> +# (since 8.2)
I still think @conventional-zones would be more obvious.
> +#
> +# @max-open-zones: The maximal number of open zones (since 8.2)
> +#
> +# @max-active-zones: The limit of the zones that have the implicit
> +# open, explicit open or closed state (since 8.2)
Maybe "The maximum number of zones in the implicit open, explicit open
or closed state".
(I'll repeat suggestions until you reject them, just to make sure they
get ignored by accident)
> +#
> +# @max-append-sectors: The maximal number of 512-byte sectors of a zone
> +# append request that can be issued to the device. (since 8.2)
> +#
> # Since: 2.12
> ##
> { 'struct': 'BlockdevCreateOptionsQcow2',
> @@ -5037,7 +5058,14 @@
> '*preallocation': 'PreallocMode',
> '*lazy-refcounts': 'bool',
> '*refcount-bits': 'int',
> -'*compression-type':'Qcow2CompressionType' } }
> +'*compression-type':'Qcow2CompressionType',
> +'*zone-model': 'uint8',
> +'*zone-size': 'size',
> +'*zone-capacity': 'size',
> +'*nr-conv-zones': 'uint32',
> +'*max-open-zones': 'uint32',
> +'*max-active-zones': 'uint32',
> +'*max-append-sectors': 'uint32' } }
>
> ##
> # @BlockdevCreateOptionsQed:
[PATCH v4 2/4] qcow2: add configurations for zoned format extension
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
---
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(-)
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
static int coroutine_fn
qcow2_co_preadv_compressed(BlockDriverState *bs,
@@ -210,6 +211,7 @@ qcow2_read_extensions(BlockDriverState *bs, uint64_t
start_offset,
uint64_t offset;
int ret;
Qcow2BitmapHeaderExt bitmaps_ext;
+Qcow2ZonedHeaderExtension zoned_ext;
if (need_update_header != NULL) {
*need_update_header = false;
@@ -431,6 +433,55 @@ qcow2_read_extensions(BlockDriverState *bs, uint64_t
start_offset,
break;
}
+case QCOW2_EXT_MAGIC_ZONED_FORMAT:
+{
+if (ext.len != sizeof(zoned_ext)) {
+error_setg(errp, "zoned_ext: Invalid extension length");
+return -EINVAL;
+}
+ret = bdrv_pread(bs->file, offset, ext.len, _ext, 0);
+if (ret < 0) {
+error_setg_errno(errp, -ret, "zoned_ext: "
+ "Could not read ext header");
+return ret;
+}
+
+zoned_ext.zone_size = be32_to_cpu(zoned_ext.zone_size);
+zoned_ext.zone_capacity = be32_to_cpu(zoned_ext.zone_capacity);
+zoned_ext.nr_conv_zones = be32_to_cpu(zoned_ext.nr_conv_zones);
+zoned_ext.nr_zones = be32_to_cpu(zoned_ext.nr_zones);
+zoned_ext.max_open_zones = be32_to_cpu(zoned_ext.max_open_zones);
+zoned_ext.max_active_zones =
+be32_to_cpu(zoned_ext.max_active_zones);
+zoned_ext.max_append_sectors =
+be32_to_cpu(zoned_ext.max_append_sectors);
+s->zoned_header = zoned_ext;
+
+/* refuse to open broken images */
+if (zoned_ext.zone_size == 0) {
+error_setg(errp, "Zoned extension header zone_size field "
+ "can not be 0");
+return -EINVAL;
+}
+if (zoned_ext.zone_capacity > zoned_ext.zone_size) {
+error_setg(errp, "Zoned extension header zone_capacity field "
+ "can not be larger that zone_size field");
+return -EINVAL;
+}
+if (zoned_ext.nr_zones != DIV_ROUND_UP(
+bs->total_sectors * BDRV_SECTOR_SIZE, zoned_ext.zone_size)) {
+error_setg(errp, "Zoned extension header nr_zones field "
+ "is wrong");
+return -EINVAL;
+}
+
+#ifdef DEBUG_EXT
+printf("Qcow2: Got zoned format extension: "
+ "offset=%" PRIu32 "\n", offset);
+#endif
+break;
+}
+
default:
/* unknown magic - save it in case we need to rewrite the header */
/* If you add a new feature, make sure to also update the fast
@@ -1967,6 +2018,14 @@ static void qcow2_refresh_limits(BlockDriverState *bs,
Error **errp)
}
bs->bl.pwrite_zeroes_alignment = s->subcluster_size;
bs->bl.pdiscard_alignment = s->cluster_size;
+bs->bl.zoned = s->zoned_header.zoned;
+bs->bl.nr_zones = s->zoned_header.nr_zones;
+bs->bl.max_append_sectors = s->zoned_header.max_append_sectors;
+bs->bl.max_active_zones = s->zoned_header.max_active_zones;
+bs->bl.max_open_zones = s->zoned_header.max_open_zones;
+bs->bl.zone_size = s->zoned_header.zone_size;
+bs->bl.zone_capacity = s->zoned_header.zone_capacity;
+bs->bl.write_granularity = BDRV_SECTOR_SIZE;
}
static int qcow2_reopen_prepare(BDRVReopenState *state,
@@ -3089,6 +3148,30 @@ int qcow2_update_header(BlockDriverState *bs)
buflen -= ret;
}
+/* Zoned devices header extension */
+if (s->zoned_header.zoned == BLK_Z_HM) {
+Qcow2ZonedHeaderExtension zoned_header = {
+.zoned =
