* [PATCH v9 0/2] qcow2: add zstd cluster compression
@ 2019-12-16 12:17 Vladimir Sementsov-Ogievskiy
2019-12-16 12:17 ` [PATCH v9 1/2] docs: improve qcow2 spec about extending image header Vladimir Sementsov-Ogievskiy
` (2 more replies)
0 siblings, 3 replies; 8+ messages in thread
From: Vladimir Sementsov-Ogievskiy @ 2019-12-16 12:17 UTC (permalink / raw)
To: qemu-devel; +Cc: kwolf, vsementsov, qemu-block, armbru, mreitz, dplotnikov, den
Hi all!
Here is my proposal, about how to correctly update qcow2 specification
to introduce new field, keeping in mind currently existing images and
downstream Qemu instances.
v9: Merge 01 and 02
Change wordings
Require header alignment
Vladimir Sementsov-Ogievskiy (2):
docs: improve qcow2 spec about extending image header
docs: qcow2: introduce compression type feature
docs/interop/qcow2.txt | 53 +++++++++++++++++++++++++++++++++++++++---
1 file changed, 50 insertions(+), 3 deletions(-)
--
2.18.0
^ permalink raw reply [flat|nested] 8+ messages in thread* [PATCH v9 1/2] docs: improve qcow2 spec about extending image header 2019-12-16 12:17 [PATCH v9 0/2] qcow2: add zstd cluster compression Vladimir Sementsov-Ogievskiy @ 2019-12-16 12:17 ` Vladimir Sementsov-Ogievskiy 2020-01-20 16:03 ` Max Reitz 2019-12-16 12:17 ` [PATCH v9 2/2] docs: qcow2: introduce compression type feature Vladimir Sementsov-Ogievskiy 2020-01-20 9:12 ` [PATCH v9 0/2] qcow2: add zstd cluster compression Vladimir Sementsov-Ogievskiy 2 siblings, 1 reply; 8+ messages in thread From: Vladimir Sementsov-Ogievskiy @ 2019-12-16 12:17 UTC (permalink / raw) To: qemu-devel; +Cc: kwolf, vsementsov, qemu-block, armbru, mreitz, dplotnikov, den Make it more obvious how to add new fields to the version 3 header and how to interpret them. The specification is adjusted so for new defined optional fields: 1. Software may support some of these optional fields and ignore the others, which means that features may be backported to downstream Qemu independently. 2. If we want to add incompatible field (or a field, for which some its values would be incompatible), it must be accompanied by incompatible feature bit. Also the concept of "default is zero" is clarified, as it's strange to say that the value of the field is assumed to be zero for the software version which don't know about the field at all and don't know how to treat it be it zero or not. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> --- docs/interop/qcow2.txt | 39 ++++++++++++++++++++++++++++++++++++--- 1 file changed, 36 insertions(+), 3 deletions(-) diff --git a/docs/interop/qcow2.txt b/docs/interop/qcow2.txt index af5711e533..d92c827763 100644 --- a/docs/interop/qcow2.txt +++ b/docs/interop/qcow2.txt @@ -79,9 +79,9 @@ The first cluster of a qcow2 image contains the file header: Offset into the image file at which the snapshot table starts. Must be aligned to a cluster boundary. -If the version is 3 or higher, the header has the following additional fields. -For version 2, the values are assumed to be zero, unless specified otherwise -in the description of a field. +For version 2, the header is exactly 72 bytes in length, and finishes here. +For version 3 or higher, the header length is at least 104 bytes, including +the next fields through header_length. 72 - 79: incompatible_features Bitmask of incompatible features. An implementation must @@ -164,6 +164,39 @@ in the description of a field. 100 - 103: header_length Length of the header structure in bytes. For version 2 images, the length is always assumed to be 72 bytes. + For version 3 it's at least 104 bytes and must be a multiply + of 8. + +Additional fields (version 3 and higher) + +In general, these fields are optional and may be safely ignored by the software, +as well as filled by zeros (which is equal to field absence), if software needs +to set field B, but don't want to care about field A, which precedes B. More +formally, additional fields have the following compatibility rules: + +1. If the value of the additional field must not be ignored for correct +handling of the file, it will be accompanied by a corresponding incompatible +feature bit. + +2. If there are no unrecognized incompatible feature bits set, an unknown +additional field may be safely ignored other than preserving its value when +rewriting the image header. + +3. An explicit value of 0 will have the same behavior as when the field is not +present*, if not altered by specific incompatible bit. + +*. Field is not present when header_length is less or equal to field's offset. +Also, all additional fields are not present for version 2. + + < ... No additional fields in the header currently ... > + +Header padding + +@header_length must be a multiply of 8, which means that if last additional field +end is not aligned, some padding is needed. This padding must be zeroed, so that, +if some existing (or future) additional field will fall into the padding, it +will be interpreted accordingly to point [3.] of the previous paragraph, i.e. +in same manner as when this field is not present. Directly after the image header, optional sections called header extensions can be stored. Each extension has a structure like the following: -- 2.18.0 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH v9 1/2] docs: improve qcow2 spec about extending image header 2019-12-16 12:17 ` [PATCH v9 1/2] docs: improve qcow2 spec about extending image header Vladimir Sementsov-Ogievskiy @ 2020-01-20 16:03 ` Max Reitz 2020-01-20 16:40 ` Vladimir Sementsov-Ogievskiy 0 siblings, 1 reply; 8+ messages in thread From: Max Reitz @ 2020-01-20 16:03 UTC (permalink / raw) To: Vladimir Sementsov-Ogievskiy, qemu-devel Cc: kwolf, qemu-block, armbru, dplotnikov, den [-- Attachment #1.1: Type: text/plain, Size: 5070 bytes --] On 16.12.19 13:17, Vladimir Sementsov-Ogievskiy wrote: > Make it more obvious how to add new fields to the version 3 header and > how to interpret them. > > The specification is adjusted so for new defined optional fields: > > 1. Software may support some of these optional fields and ignore the > others, which means that features may be backported to downstream > Qemu independently. > 2. If we want to add incompatible field (or a field, for which some its > values would be incompatible), it must be accompanied by > incompatible feature bit. > > Also the concept of "default is zero" is clarified, as it's strange to > say that the value of the field is assumed to be zero for the software > version which don't know about the field at all and don't know how to > treat it be it zero or not. > > Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> > --- > docs/interop/qcow2.txt | 39 ++++++++++++++++++++++++++++++++++++--- > 1 file changed, 36 insertions(+), 3 deletions(-) I put review of this off for so long because I always waited for Eric to give his R-b, but maybe not. I generally think that he’s stricter on what to write in documentation, and accordingly I only have nit picks on spelling and structure: > diff --git a/docs/interop/qcow2.txt b/docs/interop/qcow2.txt > index af5711e533..d92c827763 100644 > --- a/docs/interop/qcow2.txt > +++ b/docs/interop/qcow2.txt > @@ -79,9 +79,9 @@ The first cluster of a qcow2 image contains the file header: > Offset into the image file at which the snapshot table > starts. Must be aligned to a cluster boundary. > > -If the version is 3 or higher, the header has the following additional fields. > -For version 2, the values are assumed to be zero, unless specified otherwise > -in the description of a field. > +For version 2, the header is exactly 72 bytes in length, and finishes here. > +For version 3 or higher, the header length is at least 104 bytes, including > +the next fields through header_length. > > 72 - 79: incompatible_features > Bitmask of incompatible features. An implementation must > @@ -164,6 +164,39 @@ in the description of a field. > 100 - 103: header_length > Length of the header structure in bytes. For version 2 > images, the length is always assumed to be 72 bytes. > + For version 3 it's at least 104 bytes and must be a multiply s/multiply/multiple/ > + of 8. > + > +Additional fields (version 3 and higher) If this is supposed to be a heading, maybe it should enclosed by “===” on both sides. > + > +In general, these fields are optional and may be safely ignored by the software, > +as well as filled by zeros (which is equal to field absence), if software needs > +to set field B, but don't want to care about field A, which precedes B. More s/don't/does not/ (or maybe s/don't want/does not/) > +formally, additional fields have the following compatibility rules: > + > +1. If the value of the additional field must not be ignored for correct > +handling of the file, it will be accompanied by a corresponding incompatible > +feature bit. > + > +2. If there are no unrecognized incompatible feature bits set, an unknown > +additional field may be safely ignored other than preserving its value when > +rewriting the image header. > + > +3. An explicit value of 0 will have the same behavior as when the field is not > +present*, if not altered by specific incompatible bit. s/by specific/by a specific/ > + > +*. Field is not present when header_length is less or equal to field's offset. s/Field/A field/, s/field's/the field's/ (maybe also +considered, as in "A field is considered not present...") > +Also, all additional fields are not present for version 2. > + > + < ... No additional fields in the header currently ... > This looks a bit weird to me, but the next patch will remove it again, so who cares. > +Header padding Same heading note here (I’d make this “=== Header padding ===”). > + > +@header_length must be a multiply of 8, which means that if last additional field s/multiply/multiple/ > +end is not aligned, some padding is needed. This padding must be zeroed, so that, I think s/last additional field end/the last additional field’s end/, or maybe s/last additional field end/the end of the last additional field/. > +if some existing (or future) additional field will fall into the padding, it > +will be interpreted accordingly to point [3.] of the previous paragraph, i.e. > +in same manner as when this field is not present. s/in same/in the same/ > I think there should be a new heading here (“=== Header extensions ===”). Max > Directly after the image header, optional sections called header extensions can > be stored. Each extension has a structure like the following: > [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v9 1/2] docs: improve qcow2 spec about extending image header 2020-01-20 16:03 ` Max Reitz @ 2020-01-20 16:40 ` Vladimir Sementsov-Ogievskiy 0 siblings, 0 replies; 8+ messages in thread From: Vladimir Sementsov-Ogievskiy @ 2020-01-20 16:40 UTC (permalink / raw) To: Max Reitz, qemu-devel Cc: kwolf, Denis Lunev, qemu-block, armbru, Denis Plotnikov 20.01.2020 19:03, Max Reitz wrote: > On 16.12.19 13:17, Vladimir Sementsov-Ogievskiy wrote: >> Make it more obvious how to add new fields to the version 3 header and >> how to interpret them. >> >> The specification is adjusted so for new defined optional fields: >> >> 1. Software may support some of these optional fields and ignore the >> others, which means that features may be backported to downstream >> Qemu independently. >> 2. If we want to add incompatible field (or a field, for which some its >> values would be incompatible), it must be accompanied by >> incompatible feature bit. >> >> Also the concept of "default is zero" is clarified, as it's strange to >> say that the value of the field is assumed to be zero for the software >> version which don't know about the field at all and don't know how to >> treat it be it zero or not. >> >> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> >> --- >> docs/interop/qcow2.txt | 39 ++++++++++++++++++++++++++++++++++++--- >> 1 file changed, 36 insertions(+), 3 deletions(-) > > I put review of this off for so long because I always waited for Eric to > give his R-b, but maybe not. > > I generally think that he’s stricter on what to write in documentation, > and accordingly I only have nit picks on spelling and structure: This is very helpful too, thanks. I'll resend now with your suggestions, to make it easier to read for others. > >> diff --git a/docs/interop/qcow2.txt b/docs/interop/qcow2.txt >> index af5711e533..d92c827763 100644 >> --- a/docs/interop/qcow2.txt >> +++ b/docs/interop/qcow2.txt >> @@ -79,9 +79,9 @@ The first cluster of a qcow2 image contains the file header: >> Offset into the image file at which the snapshot table >> starts. Must be aligned to a cluster boundary. >> >> -If the version is 3 or higher, the header has the following additional fields. >> -For version 2, the values are assumed to be zero, unless specified otherwise >> -in the description of a field. >> +For version 2, the header is exactly 72 bytes in length, and finishes here. >> +For version 3 or higher, the header length is at least 104 bytes, including >> +the next fields through header_length. >> >> 72 - 79: incompatible_features >> Bitmask of incompatible features. An implementation must >> @@ -164,6 +164,39 @@ in the description of a field. >> 100 - 103: header_length >> Length of the header structure in bytes. For version 2 >> images, the length is always assumed to be 72 bytes. >> + For version 3 it's at least 104 bytes and must be a multiply > > s/multiply/multiple/ > >> + of 8. >> + >> +Additional fields (version 3 and higher) > > If this is supposed to be a heading, maybe it should enclosed by “===” > on both sides. > >> + >> +In general, these fields are optional and may be safely ignored by the software, >> +as well as filled by zeros (which is equal to field absence), if software needs >> +to set field B, but don't want to care about field A, which precedes B. More > > s/don't/does not/ (or maybe s/don't want/does not/) > >> +formally, additional fields have the following compatibility rules: >> + >> +1. If the value of the additional field must not be ignored for correct >> +handling of the file, it will be accompanied by a corresponding incompatible >> +feature bit. >> + >> +2. If there are no unrecognized incompatible feature bits set, an unknown >> +additional field may be safely ignored other than preserving its value when >> +rewriting the image header. >> + >> +3. An explicit value of 0 will have the same behavior as when the field is not >> +present*, if not altered by specific incompatible bit. > > s/by specific/by a specific/ > >> + >> +*. Field is not present when header_length is less or equal to field's offset. > > s/Field/A field/, s/field's/the field's/ > > (maybe also +considered, as in "A field is considered not present...") > >> +Also, all additional fields are not present for version 2. >> + >> + < ... No additional fields in the header currently ... > > > This looks a bit weird to me, but the next patch will remove it again, > so who cares. > >> +Header padding > > Same heading note here (I’d make this “=== Header padding ===”). > >> + >> +@header_length must be a multiply of 8, which means that if last additional field > > s/multiply/multiple/ > >> +end is not aligned, some padding is needed. This padding must be zeroed, so that, > > I think s/last additional field end/the last additional field’s end/, or > maybe s/last additional field end/the end of the last additional field/. > >> +if some existing (or future) additional field will fall into the padding, it >> +will be interpreted accordingly to point [3.] of the previous paragraph, i.e. >> +in same manner as when this field is not present. > > s/in same/in the same/ > >> > > I think there should be a new heading here > (“=== Header extensions ===”). > > Max > >> Directly after the image header, optional sections called header extensions can >> be stored. Each extension has a structure like the following: >> > -- Best regards, Vladimir ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH v9 2/2] docs: qcow2: introduce compression type feature 2019-12-16 12:17 [PATCH v9 0/2] qcow2: add zstd cluster compression Vladimir Sementsov-Ogievskiy 2019-12-16 12:17 ` [PATCH v9 1/2] docs: improve qcow2 spec about extending image header Vladimir Sementsov-Ogievskiy @ 2019-12-16 12:17 ` Vladimir Sementsov-Ogievskiy 2020-01-20 16:14 ` Max Reitz 2020-01-20 9:12 ` [PATCH v9 0/2] qcow2: add zstd cluster compression Vladimir Sementsov-Ogievskiy 2 siblings, 1 reply; 8+ messages in thread From: Vladimir Sementsov-Ogievskiy @ 2019-12-16 12:17 UTC (permalink / raw) To: qemu-devel; +Cc: kwolf, vsementsov, qemu-block, armbru, mreitz, dplotnikov, den The patch add new additional field to qcow2 header: compression_type, which specifies compression type. If field is absent or zero, default compression type is set: ZLIB, which corresponds to current behavior. New compression type (ZSTD) is to be added in further commit. Suggested-by: Denis Plotnikov <dplotnikov@virtuozzo.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> --- docs/interop/qcow2.txt | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/docs/interop/qcow2.txt b/docs/interop/qcow2.txt index d92c827763..77146b5169 100644 --- a/docs/interop/qcow2.txt +++ b/docs/interop/qcow2.txt @@ -109,6 +109,11 @@ the next fields through header_length. An External Data File Name header extension may be present if this bit is set. + Bit 3: Compression type bit. If this bit is set, + non-default compression is used for compressed + clusters. compression_type field must be + present and not zero. + Bits 3-63: Reserved (set to 0) 80 - 87: compatible_features @@ -188,7 +193,16 @@ present*, if not altered by specific incompatible bit. *. Field is not present when header_length is less or equal to field's offset. Also, all additional fields are not present for version 2. - < ... No additional fields in the header currently ... > + 104: compression_type + Defines the compression method used for compressed clusters. + A single compression type is applied to all compressed image + clusters. + If incompatible compression type bit is set: the field must + be present and non-zero (which means non-zlib compression type) + If incompatible compression type bit is unset: the field + may not exist or it must be zero (which means zlib). + Available compression type values: + 0: zlib <https://www.zlib.net/> Header padding -- 2.18.0 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH v9 2/2] docs: qcow2: introduce compression type feature 2019-12-16 12:17 ` [PATCH v9 2/2] docs: qcow2: introduce compression type feature Vladimir Sementsov-Ogievskiy @ 2020-01-20 16:14 ` Max Reitz 2020-01-20 16:38 ` Vladimir Sementsov-Ogievskiy 0 siblings, 1 reply; 8+ messages in thread From: Max Reitz @ 2020-01-20 16:14 UTC (permalink / raw) To: Vladimir Sementsov-Ogievskiy, qemu-devel Cc: kwolf, qemu-block, armbru, dplotnikov, den [-- Attachment #1.1: Type: text/plain, Size: 3114 bytes --] On 16.12.19 13:17, Vladimir Sementsov-Ogievskiy wrote: > The patch add new additional field to qcow2 header: compression_type, > which specifies compression type. If field is absent or zero, default > compression type is set: ZLIB, which corresponds to current behavior. > > New compression type (ZSTD) is to be added in further commit. > > Suggested-by: Denis Plotnikov <dplotnikov@virtuozzo.com> > Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> > --- > docs/interop/qcow2.txt | 16 +++++++++++++++- > 1 file changed, 15 insertions(+), 1 deletion(-) > > diff --git a/docs/interop/qcow2.txt b/docs/interop/qcow2.txt > index d92c827763..77146b5169 100644 > --- a/docs/interop/qcow2.txt > +++ b/docs/interop/qcow2.txt > @@ -109,6 +109,11 @@ the next fields through header_length. > An External Data File Name header extension may > be present if this bit is set. > > + Bit 3: Compression type bit. If this bit is set, > + non-default compression is used for compressed s/non-default/a non-default/ > + clusters. compression_type field must be > + present and not zero. s/compression_type field/The compression_type field/ > + > Bits 3-63: Reserved (set to 0) > > 80 - 87: compatible_features > @@ -188,7 +193,16 @@ present*, if not altered by specific incompatible bit. > *. Field is not present when header_length is less or equal to field's offset. > Also, all additional fields are not present for version 2. > > - < ... No additional fields in the header currently ... > > + 104: compression_type > + Defines the compression method used for compressed clusters. > + A single compression type is applied to all compressed image > + clusters. Sounds a bit too complicated. Maybe „All compressed clusters in an image use the same compression type.” instead? (Or s/an/the same/) > + If incompatible compression type bit is set: the field must Hmm, this sounds like there was an “incompatible compression type” bit, instead of an incompatible bit called “compression type”. So maybe “If the incompatible bit "compression type" is set, this field must...”? > + be present and non-zero (which means non-zlib compression type) s/$/./ > + If incompatible compression type bit is unset: the field I’d just make this “Otherwise, this field...” > + may not exist or it must be zero (which means zlib). “must not be present or must be zero”? (“exist” sounds a bit weird; the spec only defined “not present” so far. As for the “may not”, that isn’t in RFC 2119. :-)) Max > + Available compression type values: > + 0: zlib <https://www.zlib.net/> > > Header padding > > [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v9 2/2] docs: qcow2: introduce compression type feature 2020-01-20 16:14 ` Max Reitz @ 2020-01-20 16:38 ` Vladimir Sementsov-Ogievskiy 0 siblings, 0 replies; 8+ messages in thread From: Vladimir Sementsov-Ogievskiy @ 2020-01-20 16:38 UTC (permalink / raw) To: Max Reitz, qemu-devel Cc: kwolf, Denis Lunev, qemu-block, armbru, Denis Plotnikov 20.01.2020 19:14, Max Reitz wrote: > On 16.12.19 13:17, Vladimir Sementsov-Ogievskiy wrote: >> The patch add new additional field to qcow2 header: compression_type, >> which specifies compression type. If field is absent or zero, default >> compression type is set: ZLIB, which corresponds to current behavior. >> >> New compression type (ZSTD) is to be added in further commit. >> >> Suggested-by: Denis Plotnikov <dplotnikov@virtuozzo.com> >> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> >> --- >> docs/interop/qcow2.txt | 16 +++++++++++++++- >> 1 file changed, 15 insertions(+), 1 deletion(-) >> >> diff --git a/docs/interop/qcow2.txt b/docs/interop/qcow2.txt >> index d92c827763..77146b5169 100644 >> --- a/docs/interop/qcow2.txt >> +++ b/docs/interop/qcow2.txt >> @@ -109,6 +109,11 @@ the next fields through header_length. >> An External Data File Name header extension may >> be present if this bit is set. >> >> + Bit 3: Compression type bit. If this bit is set, >> + non-default compression is used for compressed > > s/non-default/a non-default/ > >> + clusters. compression_type field must be >> + present and not zero. > > s/compression_type field/The compression_type field/ > >> + >> Bits 3-63: Reserved (set to 0) >> >> 80 - 87: compatible_features >> @@ -188,7 +193,16 @@ present*, if not altered by specific incompatible bit. >> *. Field is not present when header_length is less or equal to field's offset. >> Also, all additional fields are not present for version 2. >> >> - < ... No additional fields in the header currently ... > >> + 104: compression_type >> + Defines the compression method used for compressed clusters. >> + A single compression type is applied to all compressed image >> + clusters. > > Sounds a bit too complicated. Maybe „All compressed clusters in an > image use the same compression type.” instead? (Or s/an/the same/) Sounds better, yes. > >> + If incompatible compression type bit is set: the field must > > Hmm, this sounds like there was an “incompatible compression type” bit, > instead of an incompatible bit called “compression type”. So maybe “If > the incompatible bit "compression type" is set, this field must...”? OK) > >> + be present and non-zero (which means non-zlib compression type) > > s/$/./ > >> + If incompatible compression type bit is unset: the field > > I’d just make this “Otherwise, this field...” > >> + may not exist or it must be zero (which means zlib). > > “must not be present or must be zero”? > > (“exist” sounds a bit weird; the spec only defined “not present” so far. > As for the “may not”, that isn’t in RFC 2119. :-)) Agreed, thanks. > > Max > >> + Available compression type values: >> + 0: zlib <https://www.zlib.net/> >> >> Header padding >> >> > > -- Best regards, Vladimir ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v9 0/2] qcow2: add zstd cluster compression 2019-12-16 12:17 [PATCH v9 0/2] qcow2: add zstd cluster compression Vladimir Sementsov-Ogievskiy 2019-12-16 12:17 ` [PATCH v9 1/2] docs: improve qcow2 spec about extending image header Vladimir Sementsov-Ogievskiy 2019-12-16 12:17 ` [PATCH v9 2/2] docs: qcow2: introduce compression type feature Vladimir Sementsov-Ogievskiy @ 2020-01-20 9:12 ` Vladimir Sementsov-Ogievskiy 2 siblings, 0 replies; 8+ messages in thread From: Vladimir Sementsov-Ogievskiy @ 2020-01-20 9:12 UTC (permalink / raw) To: qemu-devel Cc: kwolf, Denis Lunev, qemu-block, armbru, mreitz, Denis Plotnikov ping 16.12.2019 15:17, Vladimir Sementsov-Ogievskiy wrote: > Hi all! > > Here is my proposal, about how to correctly update qcow2 specification > to introduce new field, keeping in mind currently existing images and > downstream Qemu instances. > > v9: Merge 01 and 02 > Change wordings > Require header alignment > > Vladimir Sementsov-Ogievskiy (2): > docs: improve qcow2 spec about extending image header > docs: qcow2: introduce compression type feature > > docs/interop/qcow2.txt | 53 +++++++++++++++++++++++++++++++++++++++--- > 1 file changed, 50 insertions(+), 3 deletions(-) > -- Best regards, Vladimir ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-01-20 16:41 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-12-16 12:17 [PATCH v9 0/2] qcow2: add zstd cluster compression Vladimir Sementsov-Ogievskiy 2019-12-16 12:17 ` [PATCH v9 1/2] docs: improve qcow2 spec about extending image header Vladimir Sementsov-Ogievskiy 2020-01-20 16:03 ` Max Reitz 2020-01-20 16:40 ` Vladimir Sementsov-Ogievskiy 2019-12-16 12:17 ` [PATCH v9 2/2] docs: qcow2: introduce compression type feature Vladimir Sementsov-Ogievskiy 2020-01-20 16:14 ` Max Reitz 2020-01-20 16:38 ` Vladimir Sementsov-Ogievskiy 2020-01-20 9:12 ` [PATCH v9 0/2] qcow2: add zstd cluster compression Vladimir Sementsov-Ogievskiy
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).