Bug 1111794

This is basically this problem:

http://libguestfs.org/guestfs-faq.1.html#libguestfs-uses-too-much-disk-space

We created the appliance in $TMPDIR, as expected by experienced
libguestfs users, although probably not by everyone :-(

Upstream there are a couple of changes to make things better:

(1) You can use the --tmp option to specify the place used for the
huge temporary file.

(2) The new --in-place option (in >= 1.26) allows you to avoid the issue
entirely, since it no longer requires huge temporary files.

I would recommend trying:

  virt-sparsify --in-place disk.img

NOTE: This will OVERWRITE disk.img as it sparsifies it.  But it will
be far faster and not require much temporary space.

That link says: "It is safe to delete this directory when you are not using libguestfs."

I'm not clear on why it is left up to me to delete the directory. Seems like virt-sparsify could delete it as it is finishing up.

I don't really trust --in-place enough to want to use it without first making a copy of the image, so I figured I might as well let virt-sparsify make the copy in temp.

If --in-place is really faster and better, perhaps the two arg form of virt-sparsify should be changed to work something like this:

virt-sparsify arg1 arg2

becomes

cp arg1 arg2
virt-sparsify --in-place arg2

P.S. I didn't see any actual info request for the needinfo flag, so I'm clearing it :-).

(In reply to Tom Horsley from comment #2)
> That link says: "It is safe to delete this directory when you are not using
> libguestfs."
> 
> I'm not clear on why it is left up to me to delete the directory. Seems like
> virt-sparsify could delete it as it is finishing up.

It's stored in a temporary directory (usually, except when you
set $TMPDIR) so it would get deleted eventually by whatever it is
that cleans /tmp and /var/tmp on your operating system.

The reason we keep the cached appliance around is to avoid having
to rebuild it every time, which takes some significant amount of time.

Try doing:

rm -rf /var/tmp/.guestfs-*
time guestfish -a /dev/null run
time guestfish -a /dev/null run

You'll notice that the first run of guestfish is considerably slower
than the second and subsequent runs, because it is rebuilding the
cached appliance.

> I don't really trust --in-place enough to want to use it without first
> making a copy of the image, so I figured I might as well let virt-sparsify
> make the copy in temp.
> 
> If --in-place is really faster and better, perhaps the two arg form of
> virt-sparsify should be changed to work something like this:
> 
> virt-sparsify arg1 arg2
> 
> becomes
> 
> cp arg1 arg2
> virt-sparsify --in-place arg2

Unfortunately it's not that simple (never is ...).  The in-place
method requires recent and evolving kernel and qemu support.  It
cannot sparsify certain filesystems until kernel support is added.
For example, it cannot sparsify NTFS, because the required kernel
and filesystem support has not been done upstream.

Copying mode uses a different technique -- mounting and filling
the unused parts of the filesystem with a big file full of zeroes
and then deleting it -- and this results in better sparsification
which works on every filesystem, at the cost of having to make a
copy of the disk and using lots of temporary space.

This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

This is essentially fixed upstream, so closing.