Hi,
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@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.
https://github.com/systemd/zram-generator
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. https://github.com/systemd/zram-generator/issues
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.
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@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.
https://github.com/systemd/zram-generator
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. https://github.com/systemd/zram-generator/issues
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:
- 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
- not enable it by default, by not including a configuration file; which any edition/spin can opt-in by including their own configuration file
- 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.
Is three a question in all of this text that your expecting the IoT WG to answer?
What is the benefit of it over the existing mechanism? I don't see what advantage rust has because it's a run once and exit process, the creation of a zram device is a once of privileged process, there's no daemon that sticks around. To date the existing process for achieving a zram based swap has caused little to no issues on either the Arm images or IoT in general.
I feel something like this should be an edition/spin decision, not something across the distro.
a. Deconfliction. They don't coexist. Whichever one happens to run first will work, and the rest of them spew confusing messages. b. Getting everyone on the same page. There's no need for three of these things. Who would argue that each edition/spin needs to have their own /dev/urandom swap setup scripts, with completely different configuration files? if swap on zram is a basic thing, and I think it is, then users should be able to understand it, consistently, across the distribution, and not need a secret decoder ring to figuring out how to configure it on each edition and spin. c. Why Rust discussed in this thread a year and a half ago. But the Rust part is not as interesting and useful as the "is a generator" part, it's using an existing systemd facility well suited for this purpose, and uses existing systemd function to load the kernel module, do mkswap, and swapon, so there is a decent amount of code reuse. https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... d. There is a possibility systemd/zram-generator can be adopted across distributions, and is in a position of being more upstream than the other options so far. And that makes this even more a defacto standard and simpler for users.
Hi,
I'm following-up now that there's a preview of the change proposal ready: https://fedoraproject.org/wiki/Changes/SwapOnZRAM
Highlights:
- This is a system-wide change, for all editions and spins. - Fedora Workstation edition will no longer create swap-on-disk by default. Instead swap-on-zram will be used. - Tentative (proposed) defaults similar to 'zram' package now used by IoT: ZRAM device is 50% RAM, with a 4GiB cap. The max size, which is configurable, is to help scale ZRAM device size for more uses cases and hopefully settle on a single default Fedora wide - Obsolete 'zram' package, to avoid conflict and user confusion between the two implementations - Test day will be planned
Since Workstation edition will be doing this, it will include Workstation aarch64. And therefore I figure it's easier for IoT folks to also move to zram-generator. But correct me if I'm wrong about that, and also let me know what I can do to get Fedora IoT folks to back this change.
Thanks,
Chris Murphy
-
Chris Murphy -
Peter Robinson