Linux is capable of loading compressed kernel modules and even provides a build flag for compressing modules after installation. It even supports zstd compression since 5.13.
Is there some reason why modules in Alpine kernel packages are not compressed?
If I remember correctly, the original reasoning was that we do the compression om the modloop squashfs level, so there would be no significant gain in compressing them once again, and would only slow down things.
I guess we could consider compressing the modules and disable compression on the modloop. That way also disk installs benefits from it.
On the other side, if user is interested in compressing files, then why not do it on file system level (eg zfs or similar). Then would you compress all files, not only the kernel modules.
It would also be interesting to know if there are any preformance hit when loading the compressed modules.
I am also interested in what @fabled and @kaniini thinks about this.
Yes, I also believe that was the original reason when we were mostly run-from-tmpfs system. Given that we have increasing server installs, that would reduce the kernel modules package installed size. The fact that usually a fraction of modules are loaded and it's usually once in boot thing, this would probably make sense. While squashfs will likely compress slightly better full set of uncompressed modules, the difference is probably not too significant. I have no strong opinion here, but would be in favor of compressing the modules directly.
best option is to compress modules, but decompress before storing in squashfs, since there is a decent amount of similarity between module files. unfortunately, doing this in shell basically requires buffering all the modules again, but i think we already do that anyways, so i'm not sure it's a huge hit.
On the other side, if user is interested in compressing files, then why not do it on file system level (eg zfs or similar). Then would you compress all files, not only the kernel modules.
fs compression is not that good because it needs to allow decent performance random access (both reads and writes), so block size is kept fairly small (bad for compression).
In general I think file system compression is good, but our current setup does not support it by default. So we should either switch to zfs or btrfs by default to enable that, or enable module compression, IMO.
Should work. At least the code internally is using the seamless decryption code. If it does not work, it sounds like a bug. Assuming it's not the "small" modprobe version.
kmod depends on zstd-libs which is quite huge – 1.07 MiB. So I’d really prefer gzip, it’s much smaller and the compress ratio and decompression performance difference is not so significant to justify it IMO…
The tricky part is how/were we introduce the dependency so we dont break backwards compatibility.
We can add it as a dependency to openrc but then we "waste" 1MB on lxc containers. We could add it as dependency to the kernel itself, but kernel is not installed on "diskless" mode with the modloop, so we'd need to add special handling in the initramfs-init script.
That’s yet another reason to use gzip instead of zstd – if I understood it correctly, we can rely just on busybox and don’t need kmod package to use gzip compressed modules, right?
We save ~30MB on the cdrom image, but lose 1.4MB on tmpfs /, due to kmod.
Is it worth it? I'd say it is.
We can probably use gz and trade a few bytes on cdrom image and a little in performance to avoid kmod, but I'm kinda leaning towards using zstd. (will save me a couple of hours of reconfiguring kernel and rebuild it)
The iso image seems to become slightly smaller, probably due to the xz compression of the modloop.
I would say that this is not a significant difference and that the benefits with gz will outweight the benefit of zstd? I haven't done any performance tests.
Yes, it’s very clear that in our case, there are no significant technical benefits of zstd over gzip that would justify adding kmod and zstd-libs into the base dependencies.
Did I understand correctly that busybox tools do support kernel modules compressed with gzip?
@ncopa, i think this measurement is not correct. when i unpack modloop-lts from alpine-standard-3.15.0-x86_64.iso, decompress all modules, then repack, it shrinks from 121700352 bytes to 105144320 bytes (16556032 byte decrease). compressing modules to zstd -19 results in 112635904 bytes modloop-lts. [0] additionally, alpine-standard-3.15.0-x86_64.iso is 23068672 bytes larger than alpine-standard-3.14.0-x86_64.iso, with modloop-lts accounting for 18948096 bytes of that increase.
this is consistent with my prediction in #12857 (comment 170009) and on IRC that pre-compressing modules would cause an increase in modloop size due to poor compression of already-compressed files.
[0] test accuracy was checked by repacking without decompressing, resulted in exactly same-sized file with 3 bytes differing, probably due to timestamp