[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [Qemu-devel] [PATCH 03/20] qcow2: Extend spec for exter
Re: [Qemu-block] [Qemu-devel] [PATCH 03/20] qcow2: Extend spec for external data files
Fri, 1 Mar 2019 10:32:27 -0600
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
On 3/1/19 10:17 AM, Stefan Hajnoczi wrote:
> On Wed, Feb 27, 2019 at 06:22:39PM +0100, Kevin Wolf wrote:
>> - Bits 2-63: Reserved (set to 0)
>> + Bit 2: External data file bit. If this bit is
>> set, an
>> + external data file is used. Guest clusters
>> + then stored in the external data file. For
>> + images, clusters in the external data file
>> + not refcounted. The offset field in the
>> + Standard Cluster Descriptor must match the
>> + guest offset and neither compressed clusters
>> + nor internal snapshots are supported.
>> + An external data file name header extension
>> + be present if this bit is set.
> This sentence is clearer if the header extension name is made prominent:
> An "external data file name" header extension
> An External Data File Name header extension
> (In the previous paragraph Standard Cluster Descriptor is also
Indeed, so I like the latter suggestion.
>> @@ -148,6 +170,7 @@ be stored. Each extension has a structure like the
>> 0x6803f857 - Feature name table
>> 0x23852875 - Bitmaps extension
>> 0x0537be77 - Full disk encryption header pointer
>> + 0x44415441 - External data file name
> This new header extension isn't described in this patch?
I asked the same on v1, and the answer (which remains valid) is that
neither is 0xe2792aca Backing file format name. (In other words, both
extensions are simple enough as a single file name to be implicitly
described by the reference to the header in the earlier text). Making
both explicit wouldn't hurt my feelings, but I don't see it as a
showstopper to the patch as-is.
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org