[Top][All Lists]

[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

From: Eric Blake
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH 03/20] qcow2: Extend spec for external data files
Date: Fri, 1 Mar 2019 10:32:27 -0600
User-agent: 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 
>> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]