ZRAM zstd algorithm is overriden by lzo after kernel v6.12.5 update

In Fedora Workstation 41, after a clean install (which includes any kernel before v6.12.5) I change the ZRAM compression algorithm to zstd by editing /usr/lib/systemd/zram-generator.conf and adding the line compression-algorithm = zstd.

After a reboot the change works properly. This can be verified by running the zramctl command on the terminal.

But, since kernel v6.12.5 was deployed, ZRAM always loads the lzo-rle algorithm by itself totally ignoring the config file which was working properly just before the aforementioned kernel update.

Currently, I haven’t been able to find any way to fix this or to find any workaround for this issue. Seems it’s a bug.

1 Like

Isn’t the config file

 /etc/systemd/zram-generator.conf

?

The file you are pointing is another possibility, yes. Nevertheless, after the kernel upgrade, any zram-generator.conf file is ignored and only the lzo-rle compression algorithm is enabled.

https://bugzilla.redhat.com/show_bug.cgi?id=2332388

1 Like

Excellent, thank you!

Hello,

I’ve been researching this issue recently, but I’m unclear whether the switch to LZO-RLE is a bug or a planned change.

In my view, offering different options provides users with variety in terms of speed and performance. I use ZSTD for its high compression ratio and speed, which has worked well on an old system of mine with only 2GiB of RAM.

What confuses me is that if ZRAM in Fedora used the LZO algorithm by default, and other options were available for users to choose later, why is it no longer possible for us users to select a more suitable algorithm? Is LZO-RLE actually better than ZSTD?

Is this a bug or a feature? Should I report it (as a Fedora bug), or is there a link where I can find more official info on this change?

Thanks!

1 Like

This doesn’t belong to Proposed Common Issues (the template text of a new post contained detailed explanation what that category is - please read it next time). Moving to Ask Fedora .

Maybe it is a security measure but I have not found an explicit statement to that effect.