All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Edmondson <dme@dme.org>
To: Sam Eiderman <sameid@google.com>,
	qemu-block@nongnu.org, qemu-devel@nongnu.org
Cc: vsementsov@virtuozzo.com, Tony Zhang <tzz@google.com>,
	Max Reitz <mreitz@redhat.com>
Subject: Re: Clarification regarding new qemu-img convert --target-is-zero flag
Date: Wed, 10 Jun 2020 12:56:36 +0100	[thread overview]
Message-ID: <m2imfz877v.fsf@dme.org> (raw)
In-Reply-To: <CAFr6bU=LjeW5_eGtwL38cher2TM52skohuANNXN9EpO+mA-z8Q@mail.gmail.com>

On Wednesday, 2020-06-10 at 08:28:29 +03, Sam Eiderman wrote:

> Hi,
>
> 168468fe19c8 ("qemu-img: Add --target-is-zero to convert") has added a
> nice functionality for cloud scenarios:
>
> * Create a virtual disk
> * Convert a sparse image (qcow2, vmdk) to the virtual disk using
> --target-is-zero
> * Use the virtual disk
>
> This saves many unnecessary writes - a qcow2 with 1MB of allocated
> data but with 100GB virtual size will be converted efficiently.
>
> However, does this pose a problem if the virtual disk is not zero initialized?

As Vladimir indicated, the intent of the flag is supposed to be clear
from the name :-) If your storage doesn't read zeroes absent any earlier
writes, you probably don't want to be using it.

> Theoretically - if all unallocated blocks contain garbage - this
> shouldn't matter, however what about allocated blocks of zero? Will
> convert skip copying allocated zero blocks in the source image to the
> target since it assumes that the target is zeroed out first thing?

So something like a "--no-need-to-zero" flag would do what you want,
presuming that it would write known zeroes but no longer clean the
device before use?

dme.
-- 
You can't hide from the flipside.


  parent reply	other threads:[~2020-06-10 12:17 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-10  5:28 Clarification regarding new qemu-img convert --target-is-zero flag Sam Eiderman
2020-06-10  6:16 ` Vladimir Sementsov-Ogievskiy
2020-06-10  6:28   ` Sam Eiderman
2020-06-10 11:37     ` Kevin Wolf
2020-06-10 11:52       ` Sam Eiderman
2020-06-10 11:56 ` David Edmondson [this message]
2020-06-10 12:19   ` Sam Eiderman
2020-06-10 13:36     ` Vladimir Sementsov-Ogievskiy
2020-06-10 14:06     ` Kevin Wolf
2020-06-10 15:26       ` Sam Eiderman
2020-06-10 15:29         ` Sam Eiderman
2020-06-10 15:42           ` David Edmondson
2020-06-10 15:47             ` Sam Eiderman
2020-06-10 15:48             ` Eric Blake
2020-06-10 15:57               ` David Edmondson
2020-06-10 16:21                 ` Eric Blake
2020-06-11 10:58                   ` David Edmondson
2020-06-10 16:31         ` Kevin Wolf
2020-06-11 13:41           ` Sam Eiderman

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=m2imfz877v.fsf@dme.org \
    --to=dme@dme.org \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=sameid@google.com \
    --cc=tzz@google.com \
    --cc=vsementsov@virtuozzo.com \
    /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.