It turns out that when I was setting up Debian, I set up my “zram-generator” systemd configuration file wrong.
systemd is Hell because they never commit themselves to the idea that once you learn how to do anything with it, it will stay working, most of its components are full of bugs and security vulnerabilities, and many things replace something that some other part of the operating system was already doing a lot better.
I cringe every time I give it some new responsibility over my system, waiting for how it will go wrong. I would be using systemd-oomd to handle potential out-of-memory situations, but I’ve read so much about how it handles memory pressure bizarrely and worse than the kernel’s oom-killer, even with the Fedora defaults, that I figure I’ll just leave it alone unless it becomes “mandatory” at some point.
I hear (on Reddit) that systemd-oomd does crazy shit, like, “There are 32 GB of RAM in this system. 12 GB are in use. 20 GB are free. Let’s go on a murder spree and shut down some Chrome tabs and LibreOffice with unsaved work!”
ZRam is a compressed block device that you can use for a compressed swap file in memory. The idea isn’t a bad one, but IBM has made figuring out how to set it up unnecessarily painful because of course it is handled by systemd. You’d think setting up ZRam would be too simple for systemd to bring too much of its usual incompetence to, but nooooo.
Today I actually looked at zramctl and it told me the compression type was lzo-rle, not zstd as I wanted (and was the default on openSUSE and I’m sure that’s what it said when I set it up on Debian and started the service).
Whatever.
Looking around the Web, I found that I needed the line compression-algorithm = zstd in my /etc/systemd/zram-generator.conf file.
So I added it and rebooted, and checked sudo zramctl again and I had zstd compression. Yay!
But when I was looking at the manpage for “zram-generator”, it said that the method by which to specify the fraction of the size of RAM to use was obsolete.
zram-fraction = 1.00 does work, but it’s “obsolete”.
So now it tells me that the “current” way to do the same thing is zram-size=ram/x, where ram is the amount of ram and x is the amount to divide by.
So ram/2 would make the device half of RAM, ram/1 would make it all of your RAM, which is what I wanted.
So now my file looks like this:
# This config file enables a /dev/zram0 swap device with the following
# properties:
# * size: 50% of available RAM or 4GiB, whichever is less
# * compression-algorithm: kernel default
#
# This device’s properties can be modified by adding options under the
# `[zram0]` section, or disabled by removing the section header.
# Additional zram devices can be created by appending new `[zramX]`
# sections and setting the appropriate options for each device.
#
# See /usr/share/doc/systemd-zram-generator/zram-generator.conf.example
# and/or zram-generator.conf(5) for a list of available options.
[zram0]
zram-size=ram/1
compression-algorithm = zstd
I’m not exactly sure why IBM Red Hat keeps screwing around changing the way you do this. They make you memorize something only to make pointless changes to the way it’s done, but then the stupid thing doesn’t want to break existing setups, so they just say the old one is “obsolete”.
$ sudo zramctl
NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 zstd 15.4G 4K 64B 4K 8 [SWAP]
At least this thing is finally set up right, I think.
They never let you get too sure that you did it right or it wouldn’t be “modern”.
As to the debate about zstd vs lzo-rle, they’re both decent choices.
I can see the logic of defaulting to either one, depending on who you think your users are.
If you have a multi-core x86 PC with lots of CPU performance to burn, zstd makes more sense because of higher compression ratios.
If you have some little ARM system that you bought down at the Micro-Center and don’t want to overload it, but still do want to use ZRam, lzo-rle is a respectable choice.
If anything, ZRam with zstd has gotten faster since the kernel developers have last updated the default and I suspect it deserves another look. ⬆