Linux 5.3 Picks Up Support For Compressed Firmware Files - Measurable Storage Savings

[phoronix]

Phoronix: Linux 5.3 Picks Up Support For Compressed Firmware Files - Measurable Storage Savings

With the growing number of devices requiring loadable firmware/microcode at run-time and Linux continuing to simply support a lot more hardware, the size of /lib/firmware has ballooned in recent years while now for the upcoming Linux 5.3 kernel release is the ability to compress these firmware files for fairly significant space savings...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-Load-Compressed-Firmware

[caligula]

I'm pretty sure the distros that care about space already compress the whole filesystem. Other silly things you can do is to compress kernel modules that are stored inside a compressed initramfs.

If you really wanted to save space, how about detecting the current hardware and deleting the extra firmware. You could reinstall the firmware whenever new hardware is plugged in.

[alpha_one_x86]

zstd -22 was not more logic due the decompression speed and same or better ratio?

[geearf]

Why not just compress at the FS instead?

[Grogan]

I'm pretty sure the distros that care about space already compress the whole filesystem. Other silly things you can do is to compress kernel modules that are stored inside a compressed initramfs.

If you really wanted to save space, how about detecting the current hardware and deleting the extra firmware. You could reinstall the firmware whenever new hardware is plugged in.

Exactly... why the Hell do I need 465 Mb of /lib/firmware when the only blobs I even use in there are amdgpu/tonga_*. I haven't really cared much though (apart from philosophical wrongness), as it's easier to just install the linux-firmware package and forget about it. I'd only have to delete them all again when upgrading the package.

I don't compress kernel modules, moreover, when I used things like fglrx I used to deliberately gunzip it after -buildpkg and install. Why would I personally want extra overhead of decompressing modules at load time just to save a bit of space on terabytes of disk?

I can see it on embedded platforms though.

[boxie]

Why would I personally want extra overhead of decompressing modules at load time just to save a bit of space on terabytes of disk?

For a nominal amount of CPU you can gain a bunch of speed in loading the firmware too (as it is less to read from the disk)

[Grogan]

I have heard that rationale too. For a few modules it would be immeasurable, but I have found that the overhead of compressed filesystems doesn't convince me of that benefit.

[Guest]

I'll take a pile of uncompressed firmware blobs over shitty XZ compression. This is critical to boot times, and XZ is a bad compression format all around, not just in decompression times.

For this sort of thing (where performance matters A LOT unless someone likes waiting for their computer to boot), the only sane solution is something designed around decompression performance, like LZ4.