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 their own
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.
On Tue, Mar 17, 2020 at 10:11 PM Mohan Boddu <mboddu(a)bhujji.com> wrote:
> Peter and I talked about it a while ago about merging IoT into regular
> Fedora composes. But we never got to that point. I am not sure whats
> their plan moving forward. My idea is to merge them together and keep
> their composes as it is for their testing.
If IoT folks don't reply to this particular issue in a few days, can we
simply assume merging the composes is the best way forward for everyone and
just do it? :) I see only benefits.
This all seems like a communication issue to me, nobody wants to kick the
ball and move things forward, and everyone else is stalled.