On Mon, Jul 15, 2013 at 01:06:26PM +0200, Lukas Zapletal wrote:
On Mon, Jul 15, 2013 at 12:22:22PM +0200, Jaroslav Reznik wrote:
> downloadable cloud images (in qcow2 and raw.xz format) produced and released
I know that it is convenient to expose qcow2 images uncompressed so
users are able to upload them directly into clouds via httpd. Qcow2 is
compressed already by default (is that zlib?) so I am wondering if there
is any way of re-compressing the image with "-9" option so we are sure
the size is the best we can offer.
Currently qemu-img does not offer that. Size comparison between qcow2 vs
raw.xz shows that there are most likely some gaps we can fill in the
qcow2 size.
Just throwing in some ideas. Maybe not that relevant for this, I
apologize.
I hacked qemu code to use Z_BEST_COMPRESSION instead of Z_DEFAULT_COMPRESSION,
and got the following size results.
- qcow2 built-in compression + default level
237436928
- qcow2 built-in compression + best (9) level
236322816
- qcow2 no-compression + default gzip
218773883
- qcow2 no-compression + best (9) gzip
217264037
So the change from the default, to best level has no meaningful impact
on image size with built-in qcow2 compression. Using gzip over a
non-compressed qcow2 file is better than qcow2's built-in compression.
Given that you can't directly boot the resulting image though, the win
is not enough to outweigh the downside.
Updating to qcow2 to support xz (or some other algo) as a built-in
compression choice would likely give better results. The downside though
is that the images would be incompatible with every existing deployed
qemu/xen version out there.
So I think the choice of qcow2 with built-in compression, and raw with
external xz compression are most reasonable at this point in time.
Regards,
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|