Enhancement: use qcow2 compressed images, instead of raw-sparse

[mykaul]

Today we use raw-sparse images. This has some drawbacks:

1. It does not support file systems that don't have sparse support. It fills the whole file system, needlessly.
2. It requires us to XZ the images and ship them as XZ.

qcow2 with compression:

1. The image take 531MB (vs. 1.2GB of the raw-sparse)
2. The XZ compressed qcow2 +compression takes 513MB (so there's little point in re-compressing it).
3. The XZ compressed qcow2 takes 373MB (so should we convert to a compressed qcow2 on the client?)
4. The XZ compressed raw-sparse takes 374MB (so should we do the conversion from raw-sparse to qcow2+ compression on the client?)
5. Most importantly, at least on my laptop (SSD storage), I could not see any difference in performance (running ovirt-system-tests on top of a compressed qcow2 used as base image)
6. On my host, it took 50s to convert from raw-sparse to qcow2+compression

Note: compression does not support metadata preallocation.qemu

[gbenhaim]

1. When compressing twice the file gets bigger?
2. The only benefit that I see is [1] (because xz compress better), but can we think about a situation
   where Lago will store images on a files system that doesn't support sparse files?

[mykaul]

On Aug 3, 2017 7:53 PM, "Gal Ben Haim" <[email protected]> wrote: 1. When compressing twice the file gets bigger? 2. The only benefit that I see is [1] (because xz compress better), but can we think about a situation where Lago will store images on a files system that doesn't support sparse files? It's not support per se, the difference is that qcow2 is thin while raw sparse is just sparse. So in limited space (my /dev/shm), it won't fit. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#21 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEcJ6axXD-UDYcCpmVvDfVEbVNpoJ7e8ks5sUfsagaJpZM4Osaug> .