zram_generator::setup[…]: Warning: algorithm "…" supplemental data "…" not written: Invalid argument (os error 22)

[NikitaPuzyryov]

My /etc/systemd/zram-generator.conf is as follows:

[zram0]
zram-size = 1.5 * ram
compression-algorithm = lz4 zstd(level=1) zstd(level=3) (type=idle)
swap-priority = 100
fs-type = swap

When restarting dev-zram0.swap or rebooting the machine, the following lines appear in the journal:

zram_generator::setup[429]: Warning: algorithm "zstd" supplemental data "algo=zstd priority=1" not written: Invalid argument (os error 22)
zram_generator::setup[429]: Warning: algorithm "zstd" supplemental data "algo=zstd priority=2" not written: Invalid argument (os error 22)

Am I “holding it wrong”, lack some kernel modules, or something else? I'm also not sure how to check/verify if the zram recompress machinery works as expected.

Arch Linux, kernel 6.12.4-zen1-1-zen

[nabijaczleweli]

You should be seeing

echo lz4 > /sys/block/zram0/comp_algorithm
echo algo=zstd priority=1 > /sys/block/zram0/recomp_algorithm
echo level=1 priority=1 > /sys/block/zram0/recompress
echo algo=zstd priority=2 > /sys/block/zram0/recomp_algorithm
echo level=3 priority=1 > /sys/block/zram0/recompress

and then something related to the global config... which we aren't writing anywhere... for some reason (that reason being i forgor 💀 in a refactor).

You should be able to inspect the configuration by reading back those files.

And the warnings are coming from (probably!) the recompress parameter config. (You can verify this with running zram-generator --setup-device zram0 under strace, but I'll bet that's it actually.)

Can you try #216? That should at least log correctly.

[NikitaPuzyryov]

Fwiw cat /sys/block/zram0/recomp_algorithm shows this:

#1: lzo-rle lzo lz4 lz4hc [zstd] deflate 842
#2: lzo-rle lzo lz4 lz4hc [zstd] deflate 842

cat /sys/block/zram0/recompress says “Permission denied”

I'll figure out how to try your PR out when I get home. Cheers!

[NikitaPuzyryov]

There's a bit of a progress, modified -git package from aur to target your branch. Running v0.1.2+258+g0007613 (why there are no tags for versions 1.2+?), the errors are different:

zram_generator::setup[3660023]: Warning: algorithm "zstd" supplemental data "level=1 priority=1" not written: Invalid argument (os error 22)
zram_generator::setup[3660023]: Warning: algorithm "zstd" supplemental data "level=3 priority=2" not written: Invalid argument (os error 22)

[nabijaczleweli]

Okay so that's good that's fixed. As for the errors themselves... the documentation was misleading? seemingly? and yeah that doesn't work, and could never work. the original submitter signed off on it, but clearly didn't actually test it, so you're the tester unfortunately sorry

conferring with the drivers/block/zram/zram_drv.c implementation, i've hopefully fixed this? (all the parameters need to go to .../algorithm_params, priority= is always valid). please try updated PR?

[NikitaPuzyryov]

Running 0.1.2+259+gae93da4 and it appears that warnings are gone! Still not positive if it Works, but I guess it's a question for someplace else.

[NikitaPuzyryov]

Ugh, I just realized I have slightly different configs at home and at work: I didn't have (type=idle) at home. I just installed a version from your PR at work (where I do have (type=idle)), and got this warning:

zram_generator::setup[1112601]: Warning: configuring global recompression with "type=idle" failed: Invalid argument (os error 22)

[nabijaczleweli]

Yeah, that's probably correct. The documentation implies there's actual, persistent settable parameters, but this is not true, and /recompress only takes one-time-triggers, AFAICT from the driver code. I've updated the PR to hide them from the default config.

[NikitaPuzyryov]

Right. I've fiddled with it for a bit and also came to the conclusion that this feature is rather manual (or cronable). I also ran rg i /sys/kernel/debug/zram/zram0/block_state from time to time, and it seems like there never were any idle pages. The feature seems rather half-baked for now…

[nabijaczleweli]

This is a consistent through-line of the kernel side of the zram experience, yeah.

[OmegaSquad82]

Seems to me that, while all pages can be marked idle, the seemingly useful feature flag CONFIG_ZRAM_TRACK_ENTRY_ACTIME is unset in upstream.

The kernel-bazzite, for example, follow this lead in production builds.

I speculate that idle page recompression would be more useful when configured to crunch the oldest untouched ones first.