Artifact size difference

General Discussions
1

Hi all
I have used both ways to produce mender artifacts for pi4:

  1. using mender-convert tool

  2. using yocto and mender-binary-delta

  3. With mender convert tool, golden image was generated from raspbian image, patched with mender using mender-convert tool and mender artifact size was roughly 1.5GB

  4. With yocto and mender-binary-delta and mender-binary-delta tool, rootfs image was roughtly 60M

Why so much different in artifact size from either ways?

2

I think the main difference is, with Yocto you are creating your own distro compiling from source which usually starts with the minimum you need for a running system, whereas when you use the golden image route you are using a pre-rolled distro image from someone else which will contain a lot of stuff you probably don’t need for your use-case.

If you audit the root file systems for each disk image then you will be able to identify what is using the most storage space and determine if you need to remove packages/extra kernels/man pages from your golden image before putting it thru the mender-convert process.

Also check if you have the same compression type and level for each way of producing an artifact.

3

After yocto the generated core-image-base-raspberrypi4.sdimg image is of 1.1GB size. But when I create artifact by adding just 2 packages “sudo” and “git” in release-v.2.0, I get following artifacts :
a) release-v.1.0.mender (rootfs-image)
b) release-v.2.0.mender (rootfs-image)
c) v1.0-deltafrom-v2.0.mender (mender-binary-delta)
d) v2.0-deltafrom-v1.0.mender (mender-binary-delta)
as per Robust delta update rootfs. Here, I get much-reduced size for each artifact. How this much reduction, especially with rootfs?
a) → 56MB
b) → 68MB
c) → 95KB
d) → 5MB

4

Oh I see sorry, your using delta updates. This is not a feature i use, so will probably best be answered by @kacf as per your posted link.

6

You can not compare the size between .sdimg files and .mender files. The former files contain all four partitions, and they are uncompressed, so these will take exactly as much space as they do when written to disk. Often these are just long series of null bytes because they also contain free space, which is reduced to practically nothing when compressing. I bet if you run gzip on it, it will be a lot smaller, though usually at least twice as large as the .mender file (because it contains two copies of the rootfs partition). The .sdimg file is only used on the very first flashing though, so file size usually does not matter that much.

As for your other examples:

  • a) → 56MB
    • The base image.
  • b) → 68MB
    • You added sudo and git, which increases it by 12MB, not very surprising.
  • c) → 95KB
    • You removed sudo and git, which replaced binary data with null bytes (free space). Therefore this compresses extremely well, and is very small.
  • d) → 5MB
    • You added sudo and git, and since mender-binary-delta only computes the difference, it is much smaller than release-v.2.0. Why it is not 12MB, like the difference in a), is hard to say. Mender-binary-delta is a using a different algorithm, which happens to give different results in this case. Probably it is very dependent on exactly what the data is. You could also add --compression lzma to MENDER_ARTIFACT_EXTRA_ARGS to try a better compression algorithm (warning: it is a lot slower than gzip).