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

[David Edmondson <dme@dme.org>]

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.