[arch-general] systemd-zram generator
Hi, swap-create@.service generator for zram devices https://github.com/systemd/zram-generator zram: Compressed RAM based block devices https://www.kernel.org/doc/Documentation/blockdev/zram.txt The gist is, if a configuration file exists, a /dev/zram0 device is created during early boot and marks it for use by swap.target; so all the existing systemd stuff to mkswap and swapon gets used. The nice thing is, very low overhead. RAM is not reserved for the device, it's only consumed as needed. The generator could be installed by default, but without a configuration file. In that case, it doesn't create a swap on zram device, unless the user creates a configuration file. And at some point, the distribution can decide to include a configuration file by default. I'm thinking a useful yet conservative default would be to create a device up to 1:1 with RAM, capping out around 2G-4G. That way small RAM devices, like Pi's, get a pretty big zram device. And large RAM devices just have a smallish swap for incidental usage. One issue (reported upstream in github) is getting priority supported. I don't know whether it needs to be configurable, from the config file. But it seems sane to have the generator set a high priority, so that the zram device is used first, spilling over to a conventional swap if the user creates ones. This is a project in rust. And I think once some of the issues get worked out, it would be great if distributions can converge on this implementation. Thanks, -- Chris Murphy
From: Chris Murphy <lists@colorremedies.com> Sent: Mon Jan 13 05:51:15 CET 2020 To: <arch-general@archlinux.org> Subject: [arch-general] systemd-zram generator
Hi,
swap-create@.service generator for zram devices https://github.com/systemd/zram-generator
zram: Compressed RAM based block devices https://www.kernel.org/doc/Documentation/blockdev/zram.txt
The gist is, if a configuration file exists, a /dev/zram0 device is created during early boot and marks it for use by swap.target; so all the existing systemd stuff to mkswap and swapon gets used.
The nice thing is, very low overhead. RAM is not reserved for the device, it's only consumed as needed.
The generator could be installed by default, but without a configuration file. In that case, it doesn't create a swap on zram device, unless the user creates a configuration file. And at some point, the distribution can decide to include a configuration file by default.
I'm thinking a useful yet conservative default would be to create a device up to 1:1 with RAM, capping out around 2G-4G. That way small RAM devices, like Pi's, get a pretty big zram device. And large RAM devices just have a smallish swap for incidental usage.
One issue (reported upstream in github) is getting priority supported. I don't know whether it needs to be configurable, from the config file. But it seems sane to have the generator set a high priority, so that the zram device is used first, spilling over to a conventional swap if the user creates ones.
This is a project in rust. And I think once some of the issues get worked out, it would be great if distributions can converge on this implementation.
Thanks,
-- Chris Murphy
There are many tools to configure zram available, one is even in Arch Linux repos: https://www.archlinux.org/packages/community/any/systemd-swap/ I guess when/if systemd-zram generator will be part of systemd then distros will converge onto it. Yours sincerely G. K.
On Mon, Jan 13, 2020 at 6:45 AM Geo Kozey via arch-general <arch-general@archlinux.org> wrote:
There are many tools to configure zram available, one is even in Arch Linux repos: https://www.archlinux.org/packages/community/any/systemd-swap/
Right. And typically they don't co-exist, they expect they're the only one. So the first one that runs, works. Additional ones fail with confusing error messages - even if it's a non-fatal failure, it's kinda messy for users. I think it's inherently valuable for users to have a consistent interface for configuring something as basic as swap. Including swap on ZRAM. Is it really a feature that the user needs to know about specific implementations? As a generator, rather than a script, there's quite a bit of code reuse. It uses existing facilities in systemd to load the zram kernel module, to mkswap, and to swapon. It's much lighter weight than the existing alternatives, and is suitable for always including it in an installation by default, just like the existing swap units, rather than expecting users to manually install a package. Also, there's a better chance systemd/zram-generator can be adopted across distributions, which improves user experience. -- Chris Murphy
... installed by default ...
... Is it really a feature that the user needs to know about specific implementations?
... always including it in an installation by default, just like the existing swap units, rather than expecting users to manually install a package.
You obviously know nothing about Archlinux, maybe try researching on our Wiki before trying to force some experimental Systemd/Rust garbage on the distribution.
On Thu, Jan 16, 2020 at 4:03 AM Neven Sajko via arch-general <arch-general@archlinux.org> wrote:
... installed by default ...
... Is it really a feature that the user needs to know about specific implementations?
... always including it in an installation by default, just like the existing swap units, rather than expecting users to manually install a package.
You obviously know nothing about Archlinux,
I have done only a couple of incidental installations for general knowledge, but do have a Raspberry Pi running Arch. Is it really possible to know nothing about Archlinux in such a case?
maybe try researching on our Wiki before trying to force
It's presented as an idea. Seeing as I am such a moron, how do you suppose I'm going to go about forcing anything onto Arch Linux?
some experimental Systemd/Rust garbage on the distribution.
https://wiki.archlinux.org/index.php/Code_of_conduct I consider your response: 1. Disrespectful to me. 2. Disrespectful to other projects. 3. Trolling, because all three things I quote above must be hyperbole, they are difficult to take seriously. They are that ridiculous and unwarranted. Is this sort response representative of the Arch Linux community? Relative newcomers, and first time posters, should expect this kind of hostility? I think it's embarrassing. -- Chris Murphy
El vie., 17 ene. 2020 a las 5:18, Chris Murphy (<lists@colorremedies.com>) escribió:
Is this sort response representative of the Arch Linux community? Relative newcomers, and first time posters, should expect this kind of hostility? I think it's embarrassing.
In arch-general list can write anyone. Just ignore him. Greetings. -- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me
Hi Chris,
I consider your response: 1. Disrespectful to me.
I agree.
Is this sort response representative of the Arch Linux community?
A minority seem to think OpenBSD's, perhaps inaccurate, reputation is a target.
Relative newcomers, and first time posters, should expect this kind of hostility? I think it's embarrassing.
The majority of us think that one can write a polite reply yet still be just terse enough, emphatic where necessary, and forceful if required. Or just helpful and point the OP at material to study before returning for more assistance. Your approach didn't deserve that tone of reply. AFAICS, Neven Sajko doesn't hold any official role within Arch Linux. He, like me, writes on this mailing list, opens bugs, etc. So give the rest of us a chance. :-) -- Cheers, Ralph.
The fact is that pushing to get some experimental software installed and, especially, configured by default in Arch is rude from my viewpoint (as an Arch user), extremely so when * There are alternatives already in the Arch repos, while this one is not even packaged * "This is a project in rust." is used as an argument It kind of seemed like you were inspired by Arch's reputation of instability to think that Arch would be good testing grounds serving for eventual broad adoption of that tool. Concerning my own rudeness, a more polite response is always better (I do not consider you a moron FWIW), but that takes more consideration and time. (Regarding Systemd, it is useful as an init, but it will be a relief when it stops gobbling up userspace. And I have nothing against Rust itself.)
participants (5)
-
Chris Murphy
-
Geo Kozey
-
Neven Sajko
-
Ralph Corderoy
-
Óscar García Amor