On Wed, Nov 4, 2015 at 12:49 PM, Richard W.M. Jones <[email protected]> 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 >
_______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
