> Zswap sounds like an excellent idea to look into instead of zram. Not only
> that, but it'd allow traditional entry in fstab to configure it, instead of
> some systemd magic that nobody knows about.
In that case most of everything that happens on my system is magic, I
don't have comprehensive knowledge about everything I (possibly
indirectly) installed.
But I am a happy zram-swap user, and while I don't remember the magic
incantation I do know that I found it either in release notes or
before the relevant Fedora release on this list as a self-contained or
system-wide change.
It turns out to be even less magic than I would expect, I can easily
inspect the systemd part:
$ systemctl cat zram-swap.service
It turns out I can break the magic spell even one step further:
$ file /usr/sbin/zramstart
/usr/sbin/zramstart: Bourne-Again shell script, ASCII text executable
So the zram.noarch package is for the opposite of magic, and it is
very composable. All I needed to do was to install the package,
configure how much RAM I want to allocate for that purpose and enable
one service.
In my mind fstab isn't composable because it requires concurrent
modifications in this scenario, and is (for my limited skills) harder
to keep track of who gets to touch it.
I can't compare to other solutions, but I insist as someone who is not
knowledgeable in this area: following instructions when the
zram.noarch package landed and peeping a bit deeper felt like the
opposite of messing about with black magic.
Now the difficulty for me was to remember how I set it up "back then"
(I don't even remember when) but after a quick search I was able to
find what I was looking for thanks to a boring straightforward name:
$ systemctl | grep zram
And with my findings:
$ rpm -qf /lib/systemd/system/zram-swap.service
zram-0.4-1.fc32.noarch
Only then did I realize that it was already mentioned in this thread's
first email... But well, my memory is as persistent as my zram.
I was also aware of zram-generator but it doesn't look as polished in
terms of integration or documentation.
Dridi
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
