From: Fam Zheng <famz@redhat.com>
To: Peter Lieven <pl@kamp.de>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
qemu block <qemu-block@nongnu.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] callout to *file in bdrv_co_get_block_status
Date: Mon, 20 Mar 2017 10:46:49 +0800 [thread overview]
Message-ID: <20170320024649.GA18938@lemon.lan> (raw)
In-Reply-To: <32e1e781-f0b0-ac67-a5ce-74ccc64071a0@kamp.de>
On Fri, 03/17 12:20, Peter Lieven wrote:
> Am 17.03.2017 um 12:16 schrieb Paolo Bonzini:
> >
> > On 17/03/2017 12:11, Peter Lieven wrote:
> >>>> like VMDK or QCOW2 shouldn't we trust the information from the l2 tables in the VMDK or QCOW2?
> >>> It provides additional information, for example it works better with
> >>> prealloc=metadata.
> >> Okay, understood. Can you imagine of a away to conditionally avoid this second callout? In my case we have an additional
> >> lseek for each cluster. For a 20GB file this are approx. 327k calls to lseek. And if the file has no preallocated metadata
> >> it will likely not improve anything. And even if the metadata is prealloced what is the allocation status of the clusters?
> > If the metadata is preallocated, cluster will (or should) show up as
> > zero, speeding up the copy.
>
> Okay, in this case the second call out to *file will not happen. It only happens if the metadata says it contains data.
> So where does it actually help?
>
> The condition is: (ret & BDRV_BLOCK_DATA) && !(ret & BDRV_BLOCK_ZERO) && (ret & BDRV_BLOCK_OFFSET_VALID))
>
> So from my view it can only have any effect if the metadata returns BDRV_BLOCK_DATA, but the protocol driver returns
> BDRV_BLOCK_ZERO.
>
> This can only happen if I partially write to a cluster, or am I wrong here?
I think you have a point. The metadata should have said BDRV_BLOCK_ZERO if
protocol would say BDRV_BLOCK_ZERO - there is no reason the format driver cannot
know.
Fam
next prev parent reply other threads:[~2017-03-20 2:47 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 [this message]
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
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=20170320024649.GA18938@lemon.lan \
--to=famz@redhat.com \
--cc=pbonzini@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.