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

[Kevin Wolf <kwolf@redhat.com>]

Am 10.06.2020 um 17:26 hat Sam Eiderman geschrieben:
> 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.

I think this is a dangerous assumption to make. The guest did have
access to these unallocated blocks before, and they read as zero, so not
writing these to the conversion target does change the virtual disk.
Whether or not this is a harmless change for the guest depends on the
software running in the VM.

> 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.

Don't pretty much all SSDs support efficient zeroing/hole punching these
days so that the blocks would actually be deallocated on the disk level?

> 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)

As you noticed later, it doesn't.

The behaviour you want is more like -B, except that you don't have a
backing file. If you also pass -n, the actual filename you pass isn't
even used, so I guess '-B "" -n' should do the trick?

Kevin