[Libguestfs] Fwd: [Bug 1277705] virt-sparsify --in-place should not sparsify a snapshot

[Yaniv Kaul]

On Wed, Nov 4, 2015 at 12:49 PM, Richard W.M. Jones <rjones at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20151104/3016a66d/attachment.htm>