From: Paolo Bonzini <pbonzini@redhat.com>
To: Peter Lieven <pl@kamp.de>, Fam Zheng <famz@redhat.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
qemu block <qemu-block@nongnu.org>
Subject: Re: [Qemu-devel] callout to *file in bdrv_co_get_block_status
Date: Mon, 20 Mar 2017 15:05:17 +0100 [thread overview]
Message-ID: <f0e9decf-7b92-9218-a43f-d7d6eee10208@redhat.com> (raw)
In-Reply-To: <4aa3e0fc-1176-af7d-bef9-2b881a984605@kamp.de>
On 20/03/2017 14:35, Peter Lieven wrote:
> Am 20.03.2017 um 14:23 schrieb Paolo Bonzini:
>> On 20/03/2017 14:13, Peter Lieven wrote:
>>> Am 20.03.2017 um 13:47 schrieb Peter Lieven:
>>>> commit 5daa74a6ebce7543aaad178c4061dc087bb4c705
>>>> Author: Paolo Bonzini <pbonzini@redhat.com>
>>>> Date: Wed Sep 4 19:00:38 2013 +0200
>>>>
>>>> block: look for zero blocks in bs->file
>>>>
>>>> Reviewed-by: Eric Blake <eblake@redhat.com>
>>>> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>>>> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
>>>>
>>>>
>>>> It was introduced while introducing bdv_get_block_status. I don't know what the real
>>>>
>>>> issue was that was addressed with this patch?
>>> Is it possible that this optimization was added especially for RAW? I was believing that
>>> raw would forward the get_block_status call to bs->file, but it looks it doesn't.
>>> If this one here was for RAW would it be an option to move this callout to the raw-format driver
>>> and remove it from the generic code?
>> It was meant for both raw and qcow2.
>
> Okay, but as Fam mentioned qcow2 Metadata should know that a cluster is zero. Do you remember
> what the issue was?
I said that already---preallocated metadata. Also, at the time
pre-qcow2v3 was more important.
Are you using libiscsi, block devices or files?
Paolo
next prev parent reply other threads:[~2017-03-20 14:05 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-17 10:45 [Qemu-devel] callout to *file in bdrv_co_get_block_status Peter Lieven
2017-03-17 10:59 ` Paolo Bonzini
2017-03-17 11:11 ` Peter Lieven
2017-03-17 11:16 ` Paolo Bonzini
2017-03-17 11:20 ` Peter Lieven
2017-03-20 2:46 ` Fam Zheng
2017-03-20 11:21 ` Paolo Bonzini
2017-03-20 11:49 ` Fam Zheng
2017-03-20 12:17 ` Peter Lieven
2017-03-20 12:47 ` Peter Lieven
2017-03-20 13:13 ` Peter Lieven
2017-03-20 13:23 ` Paolo Bonzini
2017-03-20 13:35 ` Peter Lieven
2017-03-20 14:05 ` Paolo Bonzini [this message]
2017-03-20 16:43 ` Peter Lieven
2017-03-20 16:56 ` Paolo Bonzini
2017-03-27 13:21 ` Peter Lieven
2017-03-27 15:06 ` Paolo Bonzini
2017-03-31 7:55 ` Peter Lieven
2017-03-31 10:20 ` Paolo Bonzini
2017-03-17 11:24 ` Fam Zheng
2017-03-17 14:51 ` Paolo Bonzini
2017-03-18 16:16 ` Peter Lieven
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=f0e9decf-7b92-9218-a43f-d7d6eee10208@redhat.com \
--to=pbonzini@redhat.com \
--cc=famz@redhat.com \
--cc=pl@kamp.de \
--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 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.