This is a systemd generator for setting up swap on zram. If a configuration file,
/etc/systemd/zram-generator.conf, does not exist, nothing happens. If it does exist, a
zram device is created, swap-create(a)zram0.service is created and started, which does
mkswap and swapon using the same systemd logic found with either GPT swap autodiscovery
(using partition type GUID) and /dev/urandom based swap.
This has been packaged in Fedora as 'zram-generator'. While zram package works
fine and I see no problems with it, I'm liking the idea of converging on
zram-generator, to use existing logic, maintenance and bug fixing. It's also an
example of a generator made in Rust.
I've found a few issues, reported upstream, but I don't think any of them
negatively impact IoT.
There's maybe a 50/50 chance we'll get this going in Workstation for Fedora 32 in
lieu of a conventional swap partition (pretty much what IoT has been doing from the start,
correct?). But I expect to propose it as a system-wide change for Fedora 33. The idea is
to make the generator available system wide; and then we can discuss whether to:
1. enable it by default, by including a one size fits all configuration; which any
edition/spin can opt-out by either deleting the configuration file or substituting it with
2. not enable it by default, by not including a configuration file; which any edition/spin
can opt-in by including their own configuration file
3. what might possibly make sense as the most universal on size fits all configuration
Based on the anaconda zram setup; the zram package setup; brief discussion upstream, and
my own testing, I've arrived at:
Create a zram device the same size as RAM (i.e. 1:1 ratio), with a cap of 2G or 4G.
The rationale is, upstream says a zram device twice that of RAM is sane because expected
compression ratio is 2:1. But going above that really makes no sense. Therefore a 1:1
ratio is conservative enough, but it's also reasonable to go with 1:2 (1/2 that of
RAM, for the zram device size), depending on what IoT folks experience has been thus far.
The ratio will affect small RAM devices more then workstations and servers, which I expect
will pretty much always be subject to the cap.
But if this isn't what upstream zram folks want to do, then it's not a big deal to
just have a use case specific configuration files.