On Wed, Mar 06, 2013 at 06:02:01PM +0100, Paolo Bonzini wrote:
> Otherwise, live migration of the top layer will miss zero clusters and> let the backing file show through. This also matches what is done in qed.> > QCOW2_CLUSTER_ZERO clusters are invalid in v2 image files. Check this> directly in qcow2_get_cluster_offset instead of replicating the test> everywhere.> > Cc: qemu-stable@nongnu.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>> ---> block/qcow2.c | 2 +-> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
The qcow2 spec says:
Bit 0: If set to 1, the cluster reads as all zeros. The host
cluster offset can be used to describe a preallocation,
but it won't be used for reading data from this cluster,
nor is data read from the backing file if the cluster is
unallocated.
Your patch makes zero clusters "allocated", which does not violate the
preallocation case.

Il 13/03/2013 10:14, Kevin Wolf ha scritto:
>> > Otherwise, live migration of the top layer will miss zero clusters and>> > let the backing file show through. This also matches what is done in qed.>> > >> > QCOW2_CLUSTER_ZERO clusters are invalid in v2 image files. Check this>> > directly in qcow2_get_cluster_offset instead of replicating the test>> > everywhere.>> > >> > Cc: qemu-stable@nongnu.org>> > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>> Can you add a test case for this?
Yes, I'll do this.
> Also is_allocated() probably is the wrong interface now because it can> mean different things. The content of a zero cluster is indeed defined> by the image, but it may or may not be fully allocated yet. Have you> checked if the callers use it consistently in the former way?
Yes, they do. In particular, qemu-img rebase would have the same bug as
the live block jobs.
Paolo