Re: Clarification regarding new qemu-img convert --target-is-zero flag

[Sam Eiderman <sameid@google.com>]

Thanks for the clarification Kevin,

Well first I want to discuss unallocated blocks.
From my understanding operating systems do not rely on disks to be
zero initialized, on the contrary, physical disks usually contain
garbage.
So an unallocated block should never be treated as zero by any real
world application.

Now assuming that I only care about the allocated content of the
disks, I would like to save io/time zeroing out unallocated blocks.

A real world example would be flushing a 500GB vmdk on a real SSD
disk, if the vmdk contained only 2GB of data, no point in writing
498GB of zeroes to that SSD - reducing its lifespan for nothing.

Now from what I understand --target-is-zero will give me this behavior
even though that I really use it as a "--skip-prezeroing-target"
(sorry for the bad name)
(This is only true if later *allocated zeroes* are indeed copied correctly)

Sam

On Wed, Jun 10, 2020 at 5:06 PM Kevin Wolf <kwolf@redhat.com> wrote:
>
> Am 10.06.2020 um 14:19 hat Sam Eiderman geschrieben:
> > Thanks David,
> >
> > Yes, I imaging the following use case:
> >
> > disk.vmdk is a 50 GB disk that contains 12 MB binary of zeroes in its beginning.
> > /dev/sda is a raw disk containing garbage
> >
> > I invoke:
> > qemu-img convert disk.vmdk -O raw /dev/sda
> >
> > Required output:
> > The first 12 MB of /dev/sda contain zeros, the rest garbage, qemu-img
> > finishes fast.
> >
> > Kevin, from what I understood from you, this is the default behavior.
>
> Sorry, I misunderstood what you want. qemu-img will write zeros to all
> unallocated parts, too. If it didn't do that, the resulting image on
> /dev/sda wouldn't be a copy of disk.vmdk.
>
> As the metadata (which blocks are allocated) cannot be preserved in raw
> images, you wouldn't be able to tell which part of the image contains
> valid data and which part needs to be interpreted as zeros even though
> it contains random garbage.
>
> What is your use case for this result where the actual virtual disk
> content is mixed with garbage?
>
> Kevin
>