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 <kw...@redhat.com> > --- > 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
