qemu-block
[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: Eric Blake
Subject: Re: qcow2: Zero-initialization of external data files
Date: Thu, 9 Apr 2020 10:46:56 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0

On 4/9/20 10:01 AM, Max Reitz wrote:
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.

Hmm. Kevin, I'd really like your opinion here. The point of the raw-external-data flag is to state that "qemu MUST ensure that whatever is done to this image while the guest is running is reflected through to the raw file, so that after the guest stops, the raw file alone is still viable to see what the guest saw". But as you say, there's a difference between "the raw file will read what the guest saw" and "we can now edit the raw file without regards to the qcow2 wrapper but later reuse of the qcow2 wrapper won't be corrupted by those edits".

--
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]