Am 16.01.2020 um 15:37 hat Max Reitz geschrieben: > On 16.01.20 15:13, Richard W.M. Jones wrote: > > I'm not necessarily saying this is a bug, but a change in behaviour in > > qemu has caused virt-v2v to fail. The reproducer is quite simple. > > > > Create sparse and preallocated qcow2 files of the same size: > > > > $ qemu-img create -f qcow2 sparse.qcow2 50M > > Formatting 'sparse.qcow2', fmt=qcow2 size=52428800 cluster_size=65536 > > lazy_refcounts=off refcount_bits=16 > > > > $ qemu-img create -f qcow2 prealloc.qcow2 50M -o > > preallocation=falloc,compat=1.1 > > Formatting 'prealloc.qcow2', fmt=qcow2 size=52428800 compat=1.1 > > cluster_size=65536 preallocation=falloc lazy_refcounts=off refcount_bits=16 > > > > $ du -m sparse.qcow2 prealloc.qcow2 > > 1 sparse.qcow2 > > 51 prealloc.qcow2 > > > > Now copy the sparse file into the preallocated file using the -n > > option so qemu-img doesn't create the target: > > > > $ qemu-img convert -p -n -f qcow2 -O qcow2 sparse.qcow2 prealloc.qcow2 > > (100.00/100%) > > > > In new qemu that makes the target file sparse: > > > > $ du -m sparse.qcow2 prealloc.qcow2 > > 1 sparse.qcow2 > > 1 prealloc.qcow2 <-- should still be 51 > > > > In old qemu the target file remained preallocated, which is what > > I and virt-v2v are expecting. > > > > I bisected this to the following commit: > > > > 4d7c487eac1652dfe4498fe84f32900ad461d61b is the first bad commit > > commit 4d7c487eac1652dfe4498fe84f32900ad461d61b > > Author: Max Reitz <mre...@redhat.com> > > Date: Wed Jul 24 19:12:29 2019 +0200 > > > > qemu-img: Fix bdrv_has_zero_init() use in convert > > > > bdrv_has_zero_init() only has meaning for newly created images or image > > areas. If qemu-img convert did not create the image itself, it cannot > > rely on bdrv_has_zero_init()'s result to carry any meaning. > > > > Signed-off-by: Max Reitz <mre...@redhat.com> > > Message-id: 20190724171239.8764-2-mre...@redhat.com > > Reviewed-by: Maxim Levitsky <mlevi...@redhat.com> > > Reviewed-by: Stefano Garzarella <sgarz...@redhat.com> > > Signed-off-by: Max Reitz <mre...@redhat.com> > > > > qemu-img.c | 11 ++++++++--- > > 1 file changed, 8 insertions(+), 3 deletions(-) > > > > Reverting this commit on the current master branch restores the > > expected behaviour. > > The commit changed the behavior because now qemu-img realizes that it > cannot skip writing to areas that are supposed to be zero when it > converts to an existing image (because we have no idea what data that > existing image contains). So that’s a bug fix, and I don’t think we can > undo it without being wrong. > > The problem is that qemu-img will try to be quickthat about making these > areas zero, and so it does zero writes (actually, it even zeroes the > whole image) and in the process it will of course discard all preallocation. > > Now, about fixing the problem I’m not so sure.
Wouldn't just passing -S 0 solve the problem? It should tell qemu-img convert that you don't want it to sparsify anything. Kevin
signature.asc
Description: PGP signature