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