Re: qcow2: Zero-initialization of external data files

[Max Reitz]

On 09.04.20 16:32, Eric Blake wrote:
> On 4/9/20 9:10 AM, Max Reitz wrote:
> 
>>>
>>> What happens when an operation attempts to unmap things?  Do we reject
>>> all unmap operations when data-file-raw is set (thus leaving a cluster
>>> marked as allocated at all times, if we can first guarantee that
>>> preallocation set things up that way)?
>> No, unmap operations currently work.  qcow2_free_any_clusters() passes
>> them through to the external data file.
>>
>> The problem is that the unmap also zeroes the L2 entry, so if you then
>> write data to the raw file, it won’t be visible from the qcow2 side of
>> things.  However, I’m not sure whether we support modifications of a raw
>> file when it is already “in use” by a qcow2 image, so maybe that’s fine.
> 
> We don't support concurrent modification. But if the guest is running
> and unmaps things, then shuts off, then we edit the raw file offline,
> then we restart the guest, the guest should see the results of those
> offline edits.

Should it?  The specification doesn’t say anything about that.

In fact, I think we have always said we explicitly discourage that
because this might lead to outdated metadata; even though we usually
meant “dirty bitmaps” by that.

Max

signature.asc
Description: OpenPGP digital signature