On Wed, Nov 4, 2015 at 12:49 PM, Richard W.M. Jones <rjones@redhat.com> wrote:
[Let's discuss this upstream]

On Wed, Nov 04, 2015 at 12:18:48PM +0200, Yaniv Kaul wrote:
> I'm missing something here - what will happen to the tree structure?
> Will we lose it? So essentially it performs a merge?

In copying mode:

  virt-sparsify disk1 disk2

creates an overlay on top of disk1, writes zeroes to the overlay in
the parts of disk1 which are not used (disk1 is not modified by this),
and then copies the result to disk2.  It doesn't even consider any
snapshots or backing files of disk1.

        - - -

This doesn't matter because you're proposing to use --in-place which
works completely differently -- literally: it's a different code path.

  virt-sparsify --in-place disk

opens `disk', mounts each filesystem it finds in turn, and runs fstrim
on them.

The question for this bug is does that do anything useful if `disk'
has backing files?

Here is a non-sparse Fedora 22 disk image:

$ virt-builder fedora-22
$ mv fedora-22.img fedora-22.img.sparse
$ cp --sparse=never fedora-22.img.sparse fedora-22.img
$ du -sh fedora-22.img
6.1G fedora-22.img

Let's add a snapshot on top:

$ qemu-img create -f qcow2 -o compat=1.1 -b fedora-22.img overlay.qcow2
$ du -sh fedora-22.img overlay.qcow2
6.1G fedora-22.img
196K overlay.qcow2

and sparsify the overlay:

$ virt-sparsify --in-place overlay.qcow2
$ du -sh fedora-22.img overlay.qcow2
6.1G fedora-22.img
3.2M overlay.qcow2

All that happened was that the overlay got bigger (because it's now
storing a bunch of qcow2 zero clusters marking the places in the
backing file which are zero).

In *theory* it should be possible to commit the changes to the backing
file, making the backing file sparse.  But in reality that doesn't
work:

$ qemu-img commit overlay.qcow2
Image committed.
$ du -sh fedora-22.img overlay.qcow2
6.1G fedora-22.img
260K overlay.qcow2

So really there's no use for virt-sparsify on a snapshot (although you
could also argue this is a bug or missing feature in qemu-img).

Indeed, as in real life, I expect that in any level of the snapshot tree there are opportunities to sparsify blocks.
Perhaps I should run 'zerofree' when the VM is up, so the blocks become zero'ed on the right snapshot? Not sure how that would help a lot, though. It might on newer storage, which will recognize zero blocks as free on the underlying storage level.
Y.



Rich.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html