Re: [Qemu-devel] Possibly incorrect data sparsification by qemu-img

[Daniel P . Berrangé]

On Tue, Apr 23, 2019 at 12:36:02PM +0100, Richard W.M. Jones wrote:
> On Tue, Apr 23, 2019 at 01:30:28PM +0200, Martin Kletzander wrote:
> > I am using qemu-img with nbdkit to transfer a disk image and the
> > update it with extra data from newer snapshots.  The end image
> > cannot be transferred because the snapshots will be created later
> > than the first transfer and we want to save some time up front.  You
> > might think of it as a continuous synchronisation.
> 
> It's important to note here that Martin is reading the data from a
> VMware server, so this is not something that can be solved with qemu's
> own snapshots.
> 
> [...]
> 
> I think the following is an even simpler demo which gets to the nub of
> the problem as I understand it:
> 
> $ rm -f disk.img snap.img
> $ dd if=/dev/urandom of=disk.img bs=2M count=1
> $ dd if=/dev/zero of=snap.img bs=2M count=1
> $ qemu-img convert -n -p snap.img disk.img
> $ hexdump -C disk.img | head
> 00000000  18 30 e8 1f 09 f0 bb 2c  2f c7 b3 97 8f 12 fe 4b  |.0.....,/......K|
> 00000010  66 f7 28 cb 8e 72 2a 37  6b fa 98 2e a0 e6 d9 cf  |f.(..r*7k.......|
> [etc] <- ie. not zeroes
> 
> Should we expect disk.img to contain zeroes at the end?

I'd expect disk.img and snap.img to be identical when read.
snap.img doesn't have to contain zeros (it could be full of
holes instead), but a read should return all zeros.

That doesn't seem to be the case here though. It looks like
QEMU is seeing that disk.img is all zeros and then neither
writing any zeros to snap.img, not punching sparse holes in
it.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|