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
