qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: qcow2: Zero-initialization of external data files


From: Max Reitz
Subject: Re: qcow2: Zero-initialization of external data files
Date: Thu, 9 Apr 2020 17:01:24 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0

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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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