On Wed, Jun 10, 2020 at 7:31 PM Kevin Wolf <kw...@redhat.com> wrote: > 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. >
I see your point > > > 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 > >
