On Wed, Nov 04, 2015 at 01:10:04PM +0200, Yaniv Kaul wrote:
On Wed, Nov 4, 2015 at 12:49 PM, Richard W.M. Jones
<rjones(a)redhat.com>
wrote:
> 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).
^^^
Here I should have more accurately written "unused".
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.
This shouldn't make any difference, since fstrim finds all unused
space in filesystems, whether zeroes or deleted files.
> 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.
The trouble is you can't run virt-sparsify on the backing files -
you'll just end up with a corrupted disk. This is actually because
virt-sparsify mounts the filesystems within the backing file, and the
mount could replay the journal.
I think this is a qemu bug or missing feature. It should be possible
to "push" the trimmed clusters to the backing file. I'll ask Paolo.
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming and virtualization blog:
http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v