From: Eric Blake <eblake@redhat.com>
To: Max Reitz <mreitz@redhat.com>, qemu-block@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [PATCH 4/4] iotests/108: Test new refcount rebuild algorithm
Date: Wed, 10 Mar 2021 10:07:56 -0600 [thread overview]
Message-ID: <0c178b42-de16-3400-1ea8-852474ed7391@redhat.com> (raw)
In-Reply-To: <20210310155906.147478-5-mreitz@redhat.com>
On 3/10/21 9:59 AM, Max Reitz wrote:
> One clear problem with how qcow2's refcount structure rebuild algorithm
> used to be before "qcow2: Improve refcount structure rebuilding" was
> that it is prone to failure for qcow2 images on block devices: There is
> generally unused space after the actual image, and if that exceeds what
> one refblock covers, the old algorithm would invariably write the
> reftable past the block device's end, which cannot work. The new
> algorithm does not have this problem.
>
> Test it with three tests:
> (1) Create an image with more empty space at the end than what one
> refblock covers, see whether rebuilding the refcount structures
> results in a change in the image file length. (It should not.)
>
> (2) Leave precisely enough space somewhere at the beginning of the image
> for the new reftable (and the refblock for that place), see whether
> the new algorithm puts the reftable there. (It should.)
>
> (3) Test the original problem: Create (something like) a block device
> with a fixed size, then create a qcow2 image in there, write some
> data, and then have qemu-img check rebuild the refcount structures.
> Before HEAD^, the reftable would have been written past the image
> file end, i.e. outside of what the block device provides, which
> cannot work. HEAD^ should have fixed that.
> ("Something like a block device" means a loop device if we can use
> one ("sudo -n losetup" works), or a FUSE block export with
> growable=false otherwise.)
We could use qemu-nbd as another alternative to create a non-growable
protocol layer. Then we don't need root access via sudo to run the test.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
prev parent reply other threads:[~2021-03-10 16:34 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-10 15:59 [PATCH 0/4] qcow2: Improve refcount structure rebuilding Max Reitz
2021-03-10 15:59 ` [PATCH 1/4] " Max Reitz
2021-03-26 11:48 ` Vladimir Sementsov-Ogievskiy
2021-03-26 13:47 ` Max Reitz
2021-03-26 14:38 ` Vladimir Sementsov-Ogievskiy
2021-03-10 15:59 ` [PATCH 2/4] iotests/common.qemu: Add _cleanup_single_qemu Max Reitz
2021-03-10 15:59 ` [PATCH 3/4] iotests/common.qemu: Allow using the QSD Max Reitz
2021-03-10 15:59 ` [PATCH 4/4] iotests/108: Test new refcount rebuild algorithm Max Reitz
2021-03-10 16:07 ` 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=0c178b42-de16-3400-1ea8-852474ed7391@redhat.com \
--to=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 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).