From: Max Reitz <mreitz@redhat.com>
To: qemu-block@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>,
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 0/3] block: Make various formats' block_status recurse again
Date: Thu, 15 Aug 2019 17:49:30 +0200 [thread overview]
Message-ID: <40182dab-ed10-fed9-451c-e8ae2e4fa745@redhat.com> (raw)
In-Reply-To: <20190725155512.9827-1-mreitz@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 1687 bytes --]
On 25.07.19 17:55, Max Reitz wrote:
> Hi,
>
> 69f47505ee66afaa513305de0c1895a224e52c45 changed block_status so that it
> would only go down to the protocol layer if the format layer returned
> BDRV_BLOCK_RECURSE, thus indicating that it has no sufficient
> information whether a given range in the image is zero or not.
> Generally, this is because the image is preallocated and thus all ranges
> appear as zeroes.
>
> However, it only implemented this preallocation detection for qcow2.
> There are more formats that support preallocation, though: vdi, vhdx,
> vmdk, vpc. (Funny how they all start with “v”.)
>
> For vdi, vmdk, and vpc, the fix is rather simple, because they really
> have different subformats depending on whether an image is preallocated
> or not. This makes the check very simple.
>
> vhdx is more like qcow2, where after the image has been created, it
> isn’t clear whether it’s been preallocated or everything is allocated
> because everything was already written to. 69f47505ee added a heuristic
> to qcow2 to get around this, but I think that’s too much for vhdx. I
> just left it unfixed, because I don’t care that much, honestly (and I
> don’t think anyone else does).
>
>
> Max Reitz (3):
> vdi: Make block_status recurse for fixed images
> vmdk: Make block_status recurse for flat extents
> vpc: Do not return RAW from block_status
>
> block/vdi.c | 3 ++-
> block/vmdk.c | 3 +++
> block/vpc.c | 2 +-
> 3 files changed, 6 insertions(+), 2 deletions(-)
Thanks for the reviews, applied to my block-next branch:
https://git.xanclic.moe/XanClic/qemu/commits/branch/block-next
Max
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
prev parent reply other threads:[~2019-08-15 15:50 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-25 15:55 [Qemu-devel] [PATCH 0/3] block: Make various formats' block_status recurse again Max Reitz
2019-07-25 15:55 ` [Qemu-devel] [PATCH 1/3] vdi: Make block_status recurse for fixed images Max Reitz
2019-08-12 14:47 ` Vladimir Sementsov-Ogievskiy
2019-07-25 15:55 ` [Qemu-devel] [PATCH 2/3] vmdk: Make block_status recurse for flat extents Max Reitz
2019-08-12 14:59 ` Vladimir Sementsov-Ogievskiy
2019-07-25 15:55 ` [Qemu-devel] [PATCH 3/3] vpc: Do not return RAW from block_status Max Reitz
2019-08-12 15:33 ` Vladimir Sementsov-Ogievskiy
2019-08-12 15:56 ` Max Reitz
2019-08-12 16:50 ` Vladimir Sementsov-Ogievskiy
2019-08-12 19:07 ` Max Reitz
2019-08-13 10:38 ` Kevin Wolf
2019-08-13 14:49 ` Max Reitz
2019-08-12 18:39 ` [Qemu-devel] [Qemu-block] [PATCH 0/3] block: Make various formats' block_status recurse again John Snow
2019-08-12 19:11 ` Max Reitz
2019-08-12 21:45 ` John Snow
2019-08-13 14:48 ` Max Reitz
2019-08-13 22:35 ` John Snow
2019-08-15 15:49 ` Max Reitz [this message]
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=40182dab-ed10-fed9-451c-e8ae2e4fa745@redhat.com \
--to=mreitz@redhat.com \
--cc=kwolf@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=vsementsov@virtuozzo.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.