On 2/20/20 10:06 AM, Max Reitz wrote:
From: David Edmondson <david.edmond...@oracle.com>
In many cases the target of a convert operation is a newly provisioned
target that the user knows is blank (reads as zero). In this situation
there is no requirement for qemu-img to wastefully zero out the entire
device.
Add a new option, --target-is-zero, allowing the user to indicate that
an existing target device will return zeros for all reads.
Signed-off-by: David Edmondson <david.edmond...@oracle.com>
Message-Id: <20200205110248.2009589-2-david.edmond...@oracle.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsement...@virtuozzo.com>
Reviewed-by: Eric Blake <ebl...@redhat.com>
Signed-off-by: Max Reitz <mre...@redhat.com>
---
docs/interop/qemu-img.rst | 9 ++++++++-
qemu-img-cmds.hx | 4 ++--
qemu-img.c | 26 +++++++++++++++++++++++---
3 files changed, 33 insertions(+), 6 deletions(-)
diff --git a/docs/interop/qemu-img.rst b/docs/interop/qemu-img.rst
index 42e4451db4..5f40137c10 100644
--- a/docs/interop/qemu-img.rst
+++ b/docs/interop/qemu-img.rst
@@ -214,6 +214,13 @@ Parameters to convert subcommand:
will still be printed. Areas that cannot be read from the source will be
treated as containing only zeroes.
+.. option:: --target-is-zero
+
+ Assume that reading the destination image will always return
+ zeros. This parameter is mutually exclusive with a destination image
Late tweak now that this is in a pull request, so we may want a followup
patch, but:
The image doesn't always return zeros after we write to it, maybe we
should tweak this sentence:
Assume that reading the destination image will initially return all zeros.
Also, my earlier comment about 'zeroes' one line before 'zeros' still
applies - although both spellings are valid, we look inconsistent when
we can't make up our mind within two adjacent paragraphs.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org