[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 1/1] qemu-img: Add --target-is-zero to convert

From: Eric Blake
Subject: Re: [PATCH v3 1/1] qemu-img: Add --target-is-zero to convert
Date: Tue, 4 Feb 2020 07:31:52 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

On 2/4/20 3:52 AM, David Edmondson wrote:
In many cases the target of a convert operation is a newly provisioned
target that the user knows is blank (filled with zeroes). In this

'filled with zeroes' is accurate for a preallocated image, but reads awkwardly for a sparse image; it might be better to state 'reads as zero'.

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 is already zero filled.

Signed-off-by: David Edmondson <address@hidden>
  docs/interop/qemu-img.rst |  8 +++++++-
  qemu-img-cmds.hx          |  4 ++--
  qemu-img.c                | 25 ++++++++++++++++++++++---
  3 files changed, 31 insertions(+), 6 deletions(-)

diff --git a/docs/interop/qemu-img.rst b/docs/interop/qemu-img.rst
index fa27e5c7b453..99bdbe4740ee 100644
--- a/docs/interop/qemu-img.rst
+++ b/docs/interop/qemu-img.rst
@@ -214,6 +214,12 @@ 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 the destination is filled with zeros. This parameter is

Spelled 'zeroes' just three lines earlier.

+  mutually exclusive with the use of a backing file. It is required to
+  also use the ``-n`` parameter to skip image creation.

I understand that it is safer to have restrictions now and lift them later, than to allow use of the option at any time and leave room for the user to shoot themselves in the foot with no way to add safety later. The argument against no backing file is somewhat understandable (technically, as long as the backing file also reads as all zeroes, then the overall image reads as all zeroes - but why have a backing file that has no content?); the argument requiring -n is a bit weaker (if I'm creating an image, I _know_ it reads as all zeroes, so the --target-is-zero argument is redundant, but it shouldn't hurt to allow it).

+++ b/qemu-img.c

@@ -2247,6 +2256,11 @@ static int img_convert(int argc, char **argv)
          warn_report("This will become an error in future QEMU versions.");
+ if (s.has_zero_init && !skip_create) {
+        error_report("--target-is-zero requires use of -n flag");
+        goto fail_getopt;
+    }

So I think we could drop this hunk with no change in behavior.

      s.src_num = argc - optind - 1;
      out_filename = s.src_num >= 1 ? argv[argc - 1] : NULL;
@@ -2380,6 +2394,11 @@ static int img_convert(int argc, char **argv)
      s.target_has_backing = (bool) out_baseimg;
+ if (s.has_zero_init && s.target_has_backing) {
+        error_report("Cannot use --target-is-zero with a backing file");
+        goto out;
+    }

while keeping this one makes sense. At any rate, typo fixes are minor, and whether or not we drop the hunk I claim is a needless restriction against redundancy,

Reviewed-by: Eric Blake <address@hidden>

Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

reply via email to

[Prev in Thread] Current Thread [Next in Thread]