I'm not sure about LZMA, but I'd really like to see this experiment
done with LZO. The compression/decompression speeds of LZO are
fantastic, and I really don't care to shave off every bit of
compressible information as long as it doesn't impact performance as
hard as cqcow does.
There will natur
ok, I did this experiment (long and painful).
a XP2003/SP1 qemu guest required 964,231,168 bytes qcow image.
zlib qcow image became 459,686,368 bytes.
lzma estimation (4k clusters) is 437,038,838 bytes.
Yes, 5% are still gained, but the time to get the lzma'ed qcow is
disastrous (especially on s
Just there is a question:
If improvement is 5%, IS NOT THE SAME with a 5Mb HDD that with a 5Gb
HDD.
Wanna do testing with more real scenarios?
Like a Windows XP full installation for example?
I'm very sure that there will be a real difference.
Regards
El 04/07/2006, a las 15:51, Christian
for what it's worth:
qcow with "lzo -9" would become 4155352 bytes (bigger than original
zlib qcow).
yet it's true at the compression and decompression stages that it
feels faster...
On 7/4/06, Elefterios Stamatogiannakis <[EMAIL PROTECTED]> wrote:
I agree
Lzma and zlib are pretty much equival
Hi,
On Tue, 4 Jul 2006, Christian MICHON wrote:
> ok, I used "split -b 4k" on a 7716864 bytes qcow.
> I used standard lzma compression and get 1884 7z-clusters
> with a grand total of 3558617 bytes (indeed the gain is small).
>
> The standard zlib qcow gave 3704180 bytes...
That is what I expec
ok, I used "split -b 4k" on a 7716864 bytes qcow.
I used standard lzma compression and get 1884 7z-clusters
with a grand total of 3558617 bytes (indeed the gain is small).
The standard zlib qcow gave 3704180 bytes...
Does it make sense to have a cluster based compression ?
Indeed the actual comp
sorry I was not clear here...
On 7/4/06, Fabrice Bellard <[EMAIL PROTECTED]> wrote:
> how to split into individual clusters a qcow image ?
A good approximation is to use an uncompressed qcow image, or even a raw
image in which you exclude the empty clusters.
Fabrice.
how do I cut into the ac
On Tue, 2006-07-04 at 11:23 +0200, Fabrice Bellard wrote:
> Hi,
>
> I am not sure it is interesting to store the configuration of the VM in
> the disk image (there can be several disk images for a given VM).
> Moreover, extensions to the qcow header must be added at its end.
Storing the config
Christian MICHON wrote:
how do I test it unless I implement it?
Is it enough to split the qcow into the clusters, compress each one of
them, then add the total files sizes ?
Yes.
how to split into individual clusters a qcow image ?
A good approximation is to use an uncompressed qcow image,
how do I test it unless I implement it?
Is it enough to split the qcow into the clusters, compress each one of
them, then add the total files sizes ?
how to split into individual clusters a qcow image ?
On 7/4/06, Fabrice Bellard <[EMAIL PROTECTED]> wrote:
Christian MICHON wrote:
> 1) size... w
Christian MICHON wrote:
1) size... win30.qcow is 7.5Mb (no compress) 3.5Mb (with zlib)
it should go down between 2.2Mb and 2.5Mb with lzma
Did you compare with 4 KB clusters ? If you compress the whole file it
says nothing about the compression gain you will have with 4 KB blocks.
Fabrice.
I have used VMware on a Windows host with the vmdk files on a compressed
NTFS partition. The result of compression was eventually to cause the
vmdk files to become extremely fragmented (tens of thousands of fragments)
which seriously reduces performance in the end. I'm not sure why this
happens.
If it does not compress significantly better I see no need for that
(remember that qemu uses 4 KB clusters).
Fabrice.
Christian MICHON wrote:
how about also adding lzma compression for qcow ?
I know how to do this inside linux kernel, but lzma'ed qcow images
for windows guests could be a very
1) size... win30.qcow is 7.5Mb (no compress) 3.5Mb (with zlib)
it should go down between 2.2Mb and 2.5Mb with lzma
2) we can use lzma in a standalone compressor, and the decompressor is
pure C. So at least at the decompressor level, it's not really a dependency...
3) faster decompression...
On
I agree
Lzma and zlib are pretty much equivalent, so there is pretty much
nothing to be gained except slightly more compression.
On the other hand with lzo (1) there would be quite a considerable speed
improvement at the cost of compression.
It could also mean that reading on the qcow forma
Hi,
On Tue, 4 Jul 2006, Christian MICHON wrote:
> how about also adding lzma compression for qcow ?
Why lzma? We already have a dependency on zlib, why not just take that?
Ciao,
Dscho
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.no
how about also adding lzma compression for qcow ?
I know how to do this inside linux kernel, but lzma'ed qcow images
for windows guests could be a very nice addition too.
Thank Mark for the notes. I'll look at it to see how to start a
lzma patch for qcow...
On 7/4/06, Fabrice Bellard <[EMAIL PRO
Hi,
I am not sure it is interesting to store the configuration of the VM in
the disk image (there can be several disk images for a given VM).
Moreover, extensions to the qcow header must be added at its end.
Regarding my current plans, the next qcow evolution will be the support
for multiple
Nathaniel McCallum wrote:
Mark's notes on the qcow format got me to thinking how useful it would
be to be able to store other information in the qcow image itself. For
instance you could store the configuration for the virtual machine in
the image which could be extracted and then start the virt
Hi,
you said you could come up with a patch easily? Please do; it is much
easier discussing things with a working prototype.
Also, if you change the version of qcow, please make sure that you keep
the code backwards compatible: lots of people have qcow images they expect
to work in 10 years, t
Mark's notes on the qcow format got me to thinking how useful it would
be to be able to store other information in the qcow image itself. For
instance you could store the configuration for the virtual machine in
the image which could be extracted and then start the virtual machine.
So... I'm prop
21 matches
Mail list logo
