RAW images should be "as small as possible"

[e-minguez]

Currently you need to guess the size of the RAW image which is suboptimal.

It would be nice for EIB to 'sparsify' the image. https://rwmj.wordpress.com/2010/10/19/tip-making-a-disk-image-sparse/ https://libguestfs.org/virt-sparsify.1.html (virt-sparsify disk.raw --convert qcow2 disk.qcow2) and maybe generate a qcow2 image as well (I guess we use raw because the SLE Micro image is already raw but it is a waste of space)

[rdoxenham]

@e-minguez agree on the virt-sparsify, but I wouldn't convert it to qcow2. The use-case here is that you'd write the output disk to an SDcard or directly to a disk at the factory. A raw disk image shouldn't actually be any bigger (on disk) than a qcow2, but it does get interesting when you copy it :)

[e-minguez]

@e-minguez agree on the virt-sparsify, but I wouldn't convert it to qcow2. The use-case here is that you'd write the output disk to an SDcard or directly to a disk at the factory. A raw disk image shouldn't actually be any bigger (on disk) than a qcow2, but it does get interesting when you copy it :)

I guess we can probably allow both qcow2 and raw output formats (?) i.e.- for metal3 based scenarios having qcow2 is better in terms of space I guess.

[e-minguez]

Related https://github.com/Drewsif/PiShrink

[hardys]

Currently you need to guess the size of the RAW image which is suboptimal.

IMO we need to at least add some kind of validation, since currently the EIB build fails silently in the scenario where the diskSize is either omitted or too small, I think we need to do one of the following (in order of preference)

• Detect the image is too small, and fail during image-build with a message to the user (still have to guess the size)
• Same as above, but determine the actual disk size and required space, so the user knows what diskSize to specify
• Automatically resize the image so the user doesn't have to specify diskSize but when necessary the output image size is increased (to the minimum size possible)

[hardys]

@e-minguez agree on the virt-sparsify, but I wouldn't convert it to qcow2. The use-case here is that you'd write the output disk to an SDcard or directly to a disk at the factory. A raw disk image shouldn't actually be any bigger (on disk) than a qcow2, but it does get interesting when you copy it :)

I guess we can probably allow both qcow2 and raw output formats (?) i.e.- for metal3 based scenarios having qcow2 is better in terms of space I guess.

I'm not sure having native support for qcow2 is all that important, since it's easy to convert a raw to qcow2 when required, and the size difference when the image is completely full (without a backing file) is not that significant.

Also for the metal3 case, there are advantages to the raw format, since Ironic allows streaming the image to the target in that case

So IMO the main priority is to ensure we don't silently fail, and ideally to auto-resize to avoid users having to guess an appropriate diskSize (or likely picking a too-large size which definitely will waste space)

Additionally we should ensure that users can easily do a runtime growfs so that the deployed image expands to match the disk size on first boot (for the use-case where the raw image is deployed to a large disk, not SD-card of a small/fixed size)