Re: [Qemu-devel] Cluster doesn't truncate after commit to backing file

[Eric Blake]

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