From: Kevin Wolf <kwolf@redhat.com>
To: Alberto Garcia <berto@igalia.com>
Cc: "Daniel P . Berrangé" <berrange@redhat.com>,
qemu-devel@nongnu.org, qemu-block@nongnu.org,
"Max Reitz" <mreitz@redhat.com>
Subject: Re: [PATCH v2] qcow2: Forbid discard in qcow2 v2 images with backing files
Date: Fri, 27 Mar 2020 15:14:42 +0100 [thread overview]
Message-ID: <20200327141442.GA6901@linux.fritz.box> (raw)
In-Reply-To: <20200324121636.24136-1-berto@igalia.com>
Am 24.03.2020 um 13:16 hat Alberto Garcia geschrieben:
> A discard request deallocates the selected clusters so they read back
> as zeroes. This is done by clearing the cluster offset field and
> setting QCOW_OFLAG_ZERO in the L2 entry.
>
> This flag is however only supported when qcow_version >= 3. In older
> images the cluster is simply deallocated, exposing any possible stale
> data from the backing file.
>
> Since discard is an advisory operation it's safer to simply forbid it
> in this scenario.
>
> Note that we are adding this check to qcow2_co_pdiscard() and not to
> qcow2_cluster_discard() or discard_in_l2_slice() because the last
> two are also used by qcow2_snapshot_create() to discard the clusters
> used by the VM state. In this case there's no risk of exposing stale
> data to the guest and we really want that the clusters are always
> discarded.
>
> Signed-off-by: Alberto Garcia <berto@igalia.com>
The test number 289 is already taken, so this needs a rebase.
> +echo
> +echo "### Test 'qemu-io -c discard' on a QCOW2 image without a backing file"
> +echo
> +for qcow2_compat in 0.10 1.1; do
> + echo "# Create an image with compat=$qcow2_compat without a backing file"
> + _make_test_img -o "compat=$qcow2_compat" 128k
> +
> + echo "# Fill all clusters with data and then discard them"
> + $QEMU_IO -c 'write -P 0x01 0 128k' "$TEST_IMG" | _filter_qemu_io
> + $QEMU_IO -c 'discard 0 128k' "$TEST_IMG" | _filter_qemu_io
> +
> + echo "# Read the data from the discarded clusters"
> + $QEMU_IO -c 'read -P 0x00 0 128k' "$TEST_IMG" | _filter_qemu_io
> +done
How about adding a 'qemu-img map' call just to have some more direct
information about what happened to the allocation status?
> +
> +echo
> +echo "### Test 'qemu-io -c discard' on a QCOW2 image with a backing file"
> +echo
> +
> +echo "# Create a backing image and fill it with data"
> +BACKING_IMG="$TEST_IMG.base"
> +TEST_IMG="$BACKING_IMG" _make_test_img 128k
> +$QEMU_IO -c 'write -P 0xff 0 128k' "$BACKING_IMG" | _filter_qemu_io
> +
> +for qcow2_compat in 0.10 1.1; do
> + echo "# Create an image with compat=$qcow2_compat and a backing file"
> + _make_test_img -o "compat=$qcow2_compat" -b "$BACKING_IMG"
I would write some non-zero data to the backing file so that you can
later distinguish zero clusters from unallocated clusters.
> + echo "# Fill all clusters with data and then discard them"
> + $QEMU_IO -c 'write -P 0x01 0 128k' "$TEST_IMG" | _filter_qemu_io
> + $QEMU_IO -c 'discard 0 128k' "$TEST_IMG" | _filter_qemu_io
> +
> + echo "# Read the data from the discarded clusters"
> + if [ "$qcow2_compat" = "1.1" ]; then
> + # In qcow2 v3 clusters are zeroed (with QCOW_OFLAG_ZERO)
> + $QEMU_IO -c 'read -P 0x00 0 128k' "$TEST_IMG" | _filter_qemu_io
> + else
> + # In qcow2 v2 if there's a backing image we cannot zero the clusters
> + # without exposing the backing file data so discard does nothing
> + $QEMU_IO -c 'read -P 0x01 0 128k' "$TEST_IMG" | _filter_qemu_io
> + fi
> +done
Kevin
next prev parent reply other threads:[~2020-03-27 14:15 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-24 12:16 [PATCH v2] qcow2: Forbid discard in qcow2 v2 images with backing files Alberto Garcia
2020-03-24 12:43 ` Max Reitz
2020-03-27 14:14 ` Kevin Wolf [this message]
2020-03-27 16:31 ` Alberto Garcia
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=20200327141442.GA6901@linux.fritz.box \
--to=kwolf@redhat.com \
--cc=berrange@redhat.com \
--cc=berto@igalia.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.