From: Eric Blake <eblake@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [PULL 00/11] bitmaps patches for 2020-05-26
Date: Wed, 27 May 2020 15:32:47 -0500 [thread overview]
Message-ID: <b2bd3045-c49b-132f-b0c8-d928135dd226@redhat.com> (raw)
In-Reply-To: <CAFEAcA_zO06wPw=iZ-AGMF1YJp1htMJOy0_Nensn3GhWafr=EQ@mail.gmail.com>
On 5/27/20 3:07 PM, Peter Maydell wrote:
>
> iotest 190 failed on freebsd:
>
> +++ /home/qemu/qemu-test.BE3Bvf/build/tests/qemu-iotests/190.out.bad
> 2020-05-27 15:30:50.377759533 +0000
> @@ -17,7 +17,7 @@
> fully allocated size: 10813440
> required size: 2199023255552
> fully allocated size: 2199023255552
> -required size: 7012352
> +required size: 17170432
> fully allocated size: 17170432
Thanks for the heads up. That was on:
# No bitmap output, since no bitmaps on raw source
$QEMU_IMG measure -O qcow2 -f raw "$TEST_IMG"
and indicates that on FreeBSD, the qcow2 image is not as sparse as it is
on other platforms. Where Linux was able to punch holes in the
underlying filesystem, FreeBSD did not. But even though I'm not sure if
that is due to file system hole granularity, choice of APIs used to
write all-zero bitmaps, or something else, I am certain that it less
important (the qcow2 file is still quite sparse in comparison to the 2T
guest-visible data it is representing, even if it differs in sparseness
between the systems).
I'll post a v2 that filters out the required size for just that command,
as viewing a qcow2 file as if raw is unusual.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
prev parent reply other threads:[~2020-05-27 20:33 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-26 16:42 [PULL 00/11] bitmaps patches for 2020-05-26 Eric Blake
2020-05-26 16:42 ` [PULL 01/11] migration: refactor init_dirty_bitmap_migration Eric Blake
2020-05-26 16:42 ` [PULL 02/11] block/dirty-bitmap: add bdrv_has_named_bitmaps helper Eric Blake
2020-05-26 16:42 ` [PULL 03/11] migration: fix bitmaps pre-blockdev migration with mirror job Eric Blake
2020-05-26 16:42 ` [PULL 04/11] iotests: 194: test also migration of dirty bitmap Eric Blake
2020-05-26 16:42 ` [PULL 05/11] migration: add_bitmaps_to_list: check disk name once Eric Blake
2020-05-26 16:42 ` [PULL 06/11] migration: forbid bitmap migration by generated node-name Eric Blake
2020-05-26 16:42 ` [PULL 07/11] iotests: Fix test 178 Eric Blake
2020-05-26 16:42 ` [PULL 08/11] qcow2: Expose bitmaps' size during measure Eric Blake
2020-05-26 16:42 ` [PULL 09/11] qemu-img: Factor out code for merging bitmaps Eric Blake
2020-05-26 16:42 ` [PULL 10/11] qemu-img: Add convert --bitmaps option Eric Blake
2020-05-26 16:42 ` [PULL 11/11] iotests: Add test 291 to for qemu-img bitmap coverage Eric Blake
2020-05-27 20:07 ` [PULL 00/11] bitmaps patches for 2020-05-26 Peter Maydell
2020-05-27 20:32 ` Eric Blake [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=b2bd3045-c49b-132f-b0c8-d928135dd226@redhat.com \
--to=eblake@redhat.com \
--cc=peter.maydell@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).