The current oVirt WUI appliance we distribute is a raw disk, gzipped for purposes of download. When deployed it takes up 4 GB. I've been testing with qcow2 files instead. The disk creator tool installs in a raw file, but at the last step converts it to qcow2 format. This gives a uncompressed qcow2 file, with no 'wasted' space since qemu-img compresses runs of 0's. This comes in at 1.9 GB Asking it to generate a compressed qcow2 file reduces that to 683 MB. The nice thing about this is that you can deploy & run the disk straight off in this format, so the savings in space are useful both for download and deployment - whereas raw + gzip only benefits download time. To see if there's any further compression to be had for helping downloads I tried various compression programs with the following results: - gzip - 661M - bzip2 - 662M - p7zip - 617M - rzip - 586M All used their default compression levels. rzip is pretty impressive, and p7zip is not too shabby. It is clearly not worth using gzip/bzip though. IMHO, once we remove firefox / X / gnome stuff from the WUI image we'll be small enough that we need not bother with additional compression over what qcow already gives us. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
"Daniel P. Berrange" <berrange at redhat.com> wrote: ...> To see if there's any further compression to be had for helping downloads > I tried various compression programs with the following results: > > - gzip - 661M > - bzip2 - 662M > - p7zip - 617M > - rzip - 586M > > All used their default compression levels. rzip is pretty impressive, and > p7zip is not too shabby. It is clearly not worth using gzip/bzip though.Neat. If you want maximum compression, you probably don't want to use the default level. For maximum compression, try lzma with its -9 option. [yum install lzma aka http://tukaani.org/lzma/ ] But with such a big file, it'll take a long time. Though maybe it's worth it... On some quick tests, lzma -9 produced a file 15% smaller than rzip -9 did. Note that p7zip is more of an archiving program, like tar. p7zip can use LZMA for compression. The lzma program is more like gzip and bzip2.
On Tue, 2008-02-19 at 20:36 +0000, Daniel P. Berrange wrote:> To see if there's any further compression to be had for helping downloads > I tried various compression programs with the following results: > > - gzip - 661M > - bzip2 - 662M > - p7zip - 617M > - rzip - 586MDid you run these on the raw or compressed disk images ? I did a similar comparison a while ago with the surprising result that sometimes compressing a raw image gives _much_ smaller images than compressing an already compressed image. That, and the fact that VMWare can run raw disk images w/o much ado made me use raw disk images for virt-pack[1] In more detail, I played with the Mantis appliance from JumpBox. Original is zip file of 138MB. Try with raw disk files and qcow compressed inside zip and tar: raw -> qcow 69s (root disk) + 16s (data disk) = 85s zip/raw - miserable, truncates files at 4GB zip/qcow 156MB 15s tar.gz/raw 140MB 99s tar.bz2/raw 123MB 203s tar.bz2/qcow 156MB 54s tar.gz/qcow 156MB 14s 7za/raw 78MB 17m 3s As you can see, you actually get better compression if you let gzip/bzip2/7zip loose on raw disk images. They can be quite a bit slower than qemu-img though, and, of course, you have to uncompress after download, not as convenient as qcow. I always imagined though that in a managed setting downloaded disk images would be copied into storage volumes when a VM is deployed so that uncompressing wouldn't really show up as a separate step. David [1] Patches I sent to et-mgmt-tools in Dec; I don't think I ever committed them.