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