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

[Sam Eiderman]

Ok great, thanks for making it clear.

On Wed, Jun 10, 2020 at 6:42 PM David Edmondson <dme@dme.org> wrote:
>
> On Wednesday, 2020-06-10 at 18:29:33 +03, Sam Eiderman wrote:
>
> > Excuse me,
> >
> > Vladimir already pointed out in the first comment that it will skip
> > writing real zeroes later.
>
> Right. That's why you want something like "--no-need-to-zero-initialise"
> (the name keeps getting longer!), which would still write zeroes to the
> blocks that should contain zeroes, as opposed to writing zeroes to
> prepare the device.
>
> > 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
> >> >
>
> dme.
> --
> He caught a fleeting glimpse of a man, moving uphill pursued by a bus.