From: Hanna Czenczek <hreitz@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: qemu-block@nongnu.org, qemu-devel@nongnu.org,
Eric Blake <eblake@redhat.com>,
Markus Armbruster <armbru@redhat.com>
Subject: Re: [PATCH v2 03/12] block/vmdk: Change extent info type
Date: Fri, 20 Jan 2023 14:43:19 +0100 [thread overview]
Message-ID: <a79ae21b-67d1-d750-d891-652d29a0777b@redhat.com> (raw)
In-Reply-To: <Y8lfsJ5W2UxUPmWm@redhat.com>
On 19.01.23 16:20, Kevin Wolf wrote:
> Am 20.06.2022 um 18:26 hat Hanna Reitz geschrieben:
>> VMDK's implementation of .bdrv_get_specific_info() returns information
>> about its extent files, ostensibly in the form of ImageInfo objects.
>> However, it does not get this information through
>> bdrv_query_image_info(), but fills only a select few fields with custom
>> information that does not always match the fields' purposes.
>>
>> For example, @format, which is supposed to be a block driver name, is
>> filled with the extent type, e.g. SPARSE or FLAT.
>>
>> In ImageInfo, @compressed shows whether the data that can be seen in the
>> image is stored in compressed form or not. For example, a compressed
>> qcow2 image will store compressed data in its data file, but when
>> accessing the qcow2 node, you will see normal data. This is not how
>> VMDK uses the @compressed field for its extent files: Instead, it
>> signifies whether accessing the extent file will yield compressed data
>> (which the VMDK driver then (de-)compresses).
> Actually, VMDK was the only user of the field in ImageInfo. qcow2
> doesn't set the field at all because it would have to parse all L2
> tables in order to set it.
Right, makes sense.
> So I suppose @compressed can now be removed from ImageInfo?
I think so. Looks like it was indeed introduced specifically for VMDK’s extent information (cbe82d7fb32, f4c129a38a5) so that ImageInfo could be used there, which this patch here changes. So we should probably indeed remove the field – it did lead me to naïvely believe that it would have a meaning on images that actually support compression (like qcow2) after all.
Hanna
next prev parent reply other threads:[~2023-01-20 13:44 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-20 16:26 [PATCH v2 00/12] qemu-img info: Show protocol-level information Hanna Reitz
2022-06-20 16:26 ` [PATCH v2 01/12] block: Improve empty format-specific info dump Hanna Reitz
2023-01-19 14:00 ` Kevin Wolf
2023-01-20 13:35 ` Hanna Czenczek
2023-01-20 14:08 ` Kevin Wolf
2022-06-20 16:26 ` [PATCH v2 02/12] block/file: Add file-specific image info Hanna Reitz
2023-01-27 23:00 ` Eric Blake
2022-06-20 16:26 ` [PATCH v2 03/12] block/vmdk: Change extent info type Hanna Reitz
2023-01-19 15:20 ` Kevin Wolf
2023-01-20 13:43 ` Hanna Czenczek [this message]
2023-01-27 23:06 ` Eric Blake
2023-01-30 10:56 ` Kevin Wolf
2022-06-20 16:26 ` [PATCH v2 04/12] block: Split BlockNodeInfo off of ImageInfo Hanna Reitz
2022-06-20 16:26 ` [PATCH v2 05/12] qemu-img: Use BlockNodeInfo Hanna Reitz
2022-06-20 16:26 ` [PATCH v2 06/12] block/qapi: Let bdrv_query_image_info() recurse Hanna Reitz
2022-06-20 16:26 ` [PATCH v2 07/12] block/qapi: Introduce BlockGraphInfo Hanna Reitz
2022-06-20 16:27 ` [PATCH v2 08/12] block/qapi: Add indentation to bdrv_node_info_dump() Hanna Reitz
2022-06-20 16:27 ` [PATCH v2 09/12] iotests: Filter child node information Hanna Reitz
2022-06-20 16:27 ` [PATCH v2 10/12] iotests/106, 214, 308: Read only one size line Hanna Reitz
2022-06-20 16:27 ` [PATCH v2 11/12] qemu-img: Let info print block graph Hanna Reitz
2022-06-20 16:27 ` [PATCH v2 12/12] qemu-img: Change info key names for protocol nodes Hanna Reitz
2022-12-08 12:24 ` [PATCH v2 00/12] qemu-img info: Show protocol-level information Hanna Reitz
2023-01-19 20:12 ` Kevin Wolf
2023-01-20 13:44 ` Hanna Czenczek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a79ae21b-67d1-d750-d891-652d29a0777b@redhat.com \
--to=hreitz@redhat.com \
--cc=armbru@redhat.com \
--cc=eblake@redhat.com \
--cc=kwolf@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).