All of lore.kernel.org
 help / color / mirror / Atom feed
From: 叶残风 <renyime@gmail.com>
To: eblake@redhat.com
Cc: qemu-devel@nongnu.org, kwolf@redhat.com, qemu-block@nongnu.org,
	mreitz@redhat.com
Subject: Re: [Qemu-devel] [PATCH] qemu-img: return allocated size for block device with qcow2 format
Date: Thu, 03 May 2018 13:06:31 +0000	[thread overview]
Message-ID: <CA+6E1=kp+xYKEc0Xz8tj8M0r4nGb8PG+vxvxm=cDTEGCEsDTPg@mail.gmail.com> (raw)
In-Reply-To: <bc77a1b2-27f3-21a0-8d82-b930bdf033a5@redhat.com>

Thanks for your review, Eric.
Yes, the wr_highest_offset can tell the end offset at runtime, and
write_threshold similar to it. But in my situation, I need to know
the allocated end without a vm running.

Eric Blake <eblake@redhat.com> 于2018年5月2日周三 下午10:02写道:

> On 05/02/2018 08:34 AM, Ivan Ren wrote:
> > qemu-img info with a block device which has a qcow2 format always
> > return 0 for disk size, and this can not reflect the qcow2 size
> > and the used space of the block device. This patch return the
> > allocated size of qcow2 as the disk size.
>
> How does this differ from what qemu can already give you at runtime via
> the wr_highest_offset property in BlockDeviceStats, and related to the
> write_threshold ('block-set-write-threshold command,
> BLOCK_WRITE_THRESHOLD event)?  Is there any code we can reuse, rather
> than writing something from scratch?
>
> >
> > Signed-off-by: Ivan Ren <ivanren@tencent.com>
> > ---
> >   block/qcow2-bitmap.c |  69 +++++++++++++++++
> >   block/qcow2.c        | 212
> +++++++++++++++++++++++++++++++++++++++++++++++++++
> >   block/qcow2.h        |  42 ++++++++++
> >   3 files changed, 323 insertions(+)
> >
>
> --
> Eric Blake, Principal Software Engineer
> Red Hat, Inc.           +1-919-301-3266
> Virtualization:  qemu.org | libvirt.org
>

  reply	other threads:[~2018-05-03 13:06 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-02 13:34 [Qemu-devel] [PATCH] qemu-img: return allocated size for block device with qcow2 format Ivan Ren
2018-05-02 14:02 ` Eric Blake
2018-05-03 13:06   ` 叶残风 [this message]
2018-05-04 14:35     ` Max Reitz
2018-05-04 15:57       ` Ivan Ren
2018-05-02 14:37 ` Max Reitz
2018-05-02 15:01   ` Eric Blake
2018-05-02 15:13     ` Max Reitz
2018-05-02 15:19       ` Eric Blake
2018-05-02 15:33         ` Max Reitz
2018-05-03 13:08   ` 叶残风
2018-05-04 14:27     ` Max Reitz

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='CA+6E1=kp+xYKEc0Xz8tj8M0r4nGb8PG+vxvxm=cDTEGCEsDTPg@mail.gmail.com' \
    --to=renyime@gmail.com \
    --cc=eblake@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@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 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.