Re: [Qemu-devel] [Qemu-block] [RFC PATCH 01/11] qcow2: Extend spec for external data files

[Nir Soffer]

On Thu, Jan 31, 2019 at 8:43 PM Eric Blake <address@hidden> wrote:
...

> > @@ -450,8 +461,10 @@ Standard Cluster Descriptor:
>
>           1 -  8:    Reserved (set to 0)
> >
> >           9 - 55:    Bits 9-55 of host cluster offset. Must be aligned
> to a
> > -                    cluster boundary. If the offset is 0, the cluster is
> > -                    unallocated.
> > +                    cluster boundary. If the offset is 0 and bit 63 is
> clear,
> > +                    the cluster is unallocated. The offset may only be
> 0 with
> > +                    bit 63 set (indicating a host cluster offset of 0)
> when an
> > +                    external data file is used.
>
> Does that mean that the value 0x00000000 is invalid for external data
> files, and that 0x00000001 is special-cased to mean read the contents of
> the external file (and NOT that the cluster reads as all zeroes)?  Is
> bit 0 allowed to be set for any other clusters when there is an external
> data file?  And if so, are we requiring that it only be set when the
> external file is known to read as zero, or can we run into the situation
> where qcow2 says the cluster reads as 0 but the host file contains
> garbage?  Should the external file header contain a flag that states
> whether writes to the image should wipe vs. leave unchanged a cluster in
> the external file when the qcow2 metadata prefers to grab that cluster's
> contents as all-0s or by reading from the backing file?


I hope we are not going to mix qcow2 layer with data file and backing
file in the same chain.

For oVirt we would never want to have a backing chain when using qcow2
metadata layer. I think this is the same use case for KubeVirt.


> There are
> security vs. speed implications - security insists on wiping the host
> file to NOT leave stale data, but that slows things down compared to
> just leaving garbage if the qcow2 metadata can effectively ignore those
> parts of the external file - hence a knob may be worth exposing?
>

Since qcow2 is just used to managed metadata about a raw file, I don't
think it should do any optimizations like this.

What if we implement this differently - a qcow2 layer that keeps only
metadata for a backing file?

All reads will go directly to the backing file, since there is no data in
the
qcow2 file. All writes will go directly to the backing file, since no data
should
be in the qcow2 file. But before writing, update the qcow2 metadata to
reference
the cluster that will be written to the backing file.

Nir