Am 09.04.2020 um 16:32 hat Eric Blake geschrieben: > 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.
If you write to the external data file other than through qcow2, you have invalidated the qcow2 layer. You can only use the image as a raw image after this. There is no point in bending over backwards in qcow2 to allow something like this. If you're not interested in valid metadata, but want to ignore all of it, you can just use raw from the start. Kevin
