On 9/18/18 12:05 AM, lampahome wrote:
I have two image A and B, and A is the backing file of B
I write data in address addr in A.
Then create B and set A as backing file of B.
Then I discard the same addr in B.
So the entry of addr in l2 table should be 1( also is
QCOW2_CLUSTER_ZERO_PLAIN)
, right?
That is one possibility, but not the only correct one. Discard is
advisory, so whether anything happens at all is entirely up to multiple
points in the stack deciding if it is worth doing anything.
The qcow2 implementation currently enforces 'read-as-zero' semantics
when discarding a cluster that is otherwise found on a backing file.
Whether it's always the right decision, or whether we should add a knob
to make it instead be a no-op (and thus still deferring to the backing
image) is still up for debate.
But the addr cluster in A will fill with zero after I execute `qemu-img
commit B`
I thought it will truncate or decrease the ref count of the cluster
corresponding the addr, but it looks like just fill zero.
Once image B reports 'read-as-zero' for a cluster, then committing image
B into image A will remove whatever is in image A and replace it with
read-as-zero semantics. Whether it does that by actually writing zeroes
to the allocated cluster within A, or merely by leaving the data present
but converting the cluster in A to be QCOW2_CLUSTER_ZERO_ALLOC,
shouldn't matter from the semantics of what the guest reads, but again
may need a knob added if we have other reasons to control what happens
for the sake of preserving pre-allocation vs. favoring sparse images on
the host.
Is that the default behavior?
If that's what the code did, then yes. If you don't like it, patches
are welcome.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
