[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eric Blake
Subject: Re: [Qemu-devel] Cluster doesn't truncate after commit to backing file
Date: Tue, 18 Sep 2018 07:26:37 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0

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
, 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]