All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fam Zheng <famz@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Peter Lieven <pl@kamp.de>, 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: Fri, 17 Mar 2017 19:24:46 +0800	[thread overview]
Message-ID: <20170317112446.GH13125@lemon.lan> (raw)
In-Reply-To: <d41d1428-4c8b-7e2f-b197-8d45b834776d@redhat.com>

On Fri, 03/17 12:16, Paolo Bonzini wrote:
> 
> 
> 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.

I think from qemu-img convert's perspective, it doesn't care about the *file
status if the metadata already speaks, because, like you said, the data shows up
as zeroes.

In other words I think this can be optimized.

Fam

  parent reply	other threads:[~2017-03-17 11:24 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
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 [this message]
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=20170317112446.GH13125@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.