|
From: | Eric Blake |
Subject: | Re: qcow2: Zero-initialization of external data files |
Date: | Thu, 9 Apr 2020 09:32:36 -0500 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 |
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.
We have to special-case the qcow2 code to either treat unallocated cluster + raw-data-file as not really unallocated (so that we can see those edits), or we have to special case it to handle unmap + raw-data-file specially (pass unmap to the raw file, but do NOT mark the cluster unallocated in the qcow2 wrapper). Which special case we choose for unmap may in turn affect whether it is easier to require preallocation=metadata (because we can now guarantee that no cluster will ever be marked unallocated in qcow2) or whether the default preallocation of leaving clusters "unallocated" in qcow2 still sees the proper guest data.
-- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
[Prev in Thread] | Current Thread | [Next in Thread] |