<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Nov 4, 2015 at 12:49 PM, Richard W.M. Jones <span dir="ltr"><<a href="mailto:rjones@redhat.com" target="_blank">rjones@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[Let's discuss this upstream]<br>
<span><br>
On Wed, Nov 04, 2015 at 12:18:48PM +0200, Yaniv Kaul wrote:<br>
> I'm missing something here - what will happen to the tree structure?<br>
> Will we lose it? So essentially it performs a merge?<br>
<br>
</span>In copying mode:<br>
<br>
  virt-sparsify disk1 disk2<br>
<br>
creates an overlay on top of disk1, writes zeroes to the overlay in<br>
the parts of disk1 which are not used (disk1 is not modified by this),<br>
and then copies the result to disk2.  It doesn't even consider any<br>
snapshots or backing files of disk1.<br>
<br>
        - - -<br>
<br>
This doesn't matter because you're proposing to use --in-place which<br>
works completely differently -- literally: it's a different code path.<br>
<br>
  virt-sparsify --in-place disk<br>
<br>
opens `disk', mounts each filesystem it finds in turn, and runs fstrim<br>
on them.<br>
<br>
The question for this bug is does that do anything useful if `disk'<br>
has backing files?<br>
<br>
Here is a non-sparse Fedora 22 disk image:<br>
<br>
$ virt-builder fedora-22<br>
$ mv fedora-22.img fedora-22.img.sparse<br>
$ cp --sparse=never fedora-22.img.sparse fedora-22.img<br>
$ du -sh fedora-22.img<br>
6.1G fedora-22.img<br>
<br>
Let's add a snapshot on top:<br>
<br>
$ qemu-img create -f qcow2 -o compat=1.1 -b fedora-22.img overlay.qcow2<br>
$ du -sh fedora-22.img overlay.qcow2<br>
6.1G fedora-22.img<br>
196K overlay.qcow2<br>
<br>
and sparsify the overlay:<br>
<br>
$ virt-sparsify --in-place overlay.qcow2<br>
$ du -sh fedora-22.img overlay.qcow2<br>
6.1G fedora-22.img<br>
3.2M overlay.qcow2<br>
<br>
All that happened was that the overlay got bigger (because it's now<br>
storing a bunch of qcow2 zero clusters marking the places in the<br>
backing file which are zero).<br>
<br>
In *theory* it should be possible to commit the changes to the backing<br>
file, making the backing file sparse.  But in reality that doesn't<br>
work:<br>
<br>
$ qemu-img commit overlay.qcow2<br>
Image committed.<br>
$ du -sh fedora-22.img overlay.qcow2<br>
6.1G fedora-22.img<br>
260K overlay.qcow2<br>
<br>
So really there's no use for virt-sparsify on a snapshot (although you<br>
could also argue this is a bug or missing feature in qemu-img).<br></blockquote><div><br></div><div>Indeed, as in real life, I expect that in any level of the snapshot tree there are opportunities to sparsify blocks.</div><div>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.</div><div>Y.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Rich.<br>
<span><font color="#888888"><br>
--<br>
Richard Jones, Virtualization Group, Red Hat <a href="http://people.redhat.com/~rjones" rel="noreferrer" target="_blank">http://people.redhat.com/~rjones</a><br>
Read my programming and virtualization blog: <a href="http://rwmj.wordpress.com" rel="noreferrer" target="_blank">http://rwmj.wordpress.com</a><br>
virt-builder quickly builds VMs from scratch<br>
<a href="http://libguestfs.org/virt-builder.1.html" rel="noreferrer" target="_blank">http://libguestfs.org/virt-builder.1.html</a><br>
</font></span></blockquote></div><br></div></div>