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 >> are >> + then stored in the external data file. For >> such >> + images, clusters in the external data file >> are >> + 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 >> may >> + 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 > > Or > > An External Data File Name header extension > > (In the previous paragraph Standard Cluster Descriptor is also > capitalized.)
Indeed, so I like the latter suggestion. > >> @@ -148,6 +170,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 > > 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
