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

[Sam Eiderman]

Excuse me,

Vladimir already pointed out in the first comment that it will skip
writing real zeroes later.

Sam

On Wed, Jun 10, 2020 at 6:26 PM Sam Eiderman <sameid@google.com> wrote:
>
> 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
> >