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

[Eric Blake]

On 1/31/19 11:55 AM, Kevin Wolf wrote:
> This adds external data file to the qcow2 spec as a new incompatible
> feature.
> 
> Signed-off-by: Kevin Wolf <address@hidden>
> ---
>  docs/interop/qcow2.txt | 19 ++++++++++++++++---
>  1 file changed, 16 insertions(+), 3 deletions(-)
> 

> @@ -148,6 +158,7 @@ be stored. Each extension has a structure like the 
> following:
>                          0x6803f857 - Feature name table
>                          0x23852875 - Bitmaps extension
>                          0x0537be77 - Full disk encryption header pointer
> +                        0x44415441 - External data file name
>                          other      - Unknown header extension, can be safely
>                                       ignored

Missing a section describing the new header.

>  
> @@ -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?  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?

Should we preserve the meaning of bit 0 SOLELY for its 'reads-as-zeroes'
meaning, and instead make bit 1 (currently reserved) as the special
marker that MUST be set for clusters read from the external file,
keeping the two ideas orthogonal?

Worth a mention on the reftable section that when an external file is
used, metadata clusters (in the qcow2 file) are still refcounted (and
thus, offsets in the refcount table point to the qcow2 file, not the
external file)?

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

signature.asc
Description: OpenPGP digital signature