Re: [PATCH 1/2] qcow2: Force preallocation with data-file-raw

[Eric Blake <eblake@redhat.com>]

On 6/22/20 10:48 AM, Max Reitz wrote:

>>> As I noted in my reply to myself, data-file-raw is an autoclear flag.
>>> That means, an old version of qemu that doesn’t recognize the flag must
>>> read the same data as a new version.  It follows that the the L2 tables
>>> must be a 1:1 mapping.  (Or the flag can’t be an autoclear flag.)

Yes, that argument is the strongest I've seen for why both creation and 
resize with a data-file-raw image should require metadata preallocation. 
  In other words, we never want to expose different guest data merely 
because we opened the file with an older version (the older version must 
either see the same data [an autoclear bit is fine], or must know that 
it cannot reliably open the image [an incompatible bit is needed]).

>>
>> Being able to read sounds like a nice to have feature, but what about writing?
>>
>> I hope that the image is not writable by older versions that do not understand
>> data_file. Otherwise older qemu versions can corrupt the image silently.
> 
> It’s an autoclear flag.  That means such versions of qemu will
> automatically clear the flag.

Well, an older version is only required to clear the flag if it modifies 
the image; if it opens the image read-only, it may leave the autoclear 
flag set.  So you are more realistically guaranteed that the autoclear 
flag is only cleared when writing to the image with a version that did 
not understand the autoclear flag.

Following that line of thought further - reopening the image under a 
qemu that once again understands the data-file-raw flag will now see 
that the file is no longer raw because the flag was cleared.  That is, 
if you are expecting data-file-raw and no longer see the flag, then you 
KNOW that the qcow2 file was modified by an older program that didn't 
necessarily preserve the 1:1 correspondence, and it is up to you what to 
do next (refuse to use the file, do a pass over the qcow2 file to flush 
contents back to the raw file, or any number of other reactions...).

> So autoclear flags are useful for features that are optional, but that
> may be broken when the image is written to by versions of qemu that
> don’t understand them.)

More importantly, autoclear flags are useful for features where older 
software can safely read the image without data loss, but where older 
software modifying the image may lose whatever property the bit was 
guaranteeing when interpreted correctly.

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