I don’t know if this is the right category to post this. I’d like to get suggestions from other users, but I’m also giving feedback about the way Fedora is built, that could hopefully reach the development team.
I used to have a laptop with 4 GB of RAM, swap, and an HDD. When I ran out of RAM, the whole system would start to freeze (not only the app that’s consuming a lot of RAM). This is probably the case where zram could help.
I now have a laptop with 8 GB of RAM, and an SDD. I used to have Ubuntu and it worked great RAM and performance wise.
But now I’ve installed Fedora and it uses swap-on-zram instead of swap on disk, which means my available memory is limited by just a bit larger than the amount of RAM I have.
I think the decision to use the early OOM killer is good, since the machine doesn’t slow down, but when I run out of memory, due to it, my Brave (Chromium-based browser) are getting killed, which is quite annoying, especially when working under time pressure to meet a deadline.
On my laptop, my user experience has worsened due to this.
Furthermore, I won’t be able to hibernate my machine this way.
I’m asking 3 things:
What was the rationale for choosing zram, especially on a setup like this?
I think that, for SSD users, regular swap should be used by default, and a clear option to use swap should be available.
What’s a suggested way to disable zram and revert back to regular swap?
But I’m not quite sure I understand the scenario you’re describing. From what I’ve seen, zram helps significantly in tight memory situations, as it’s typical to get 2× or 3× compression.
Disabling zram on swap is described in the change proposal here:
Thanks for the instructions to disable it!
But I’m not quite sure I understand the scenario you’re describing. From what I’ve seen, zram helps significantly in tight memory situations, as it’s typical to get 2× or 3× compression.
Yeah, you might have more RAM but for example I use multiple Electron apps, GNOME and a Chromium-based browser, which eat up the RAM. The moment you run out of RAM your browser tabs keep getting killed. I could screenshot it the next thing it happens, as it’s quite annoying, and in the worst case scenario you’re filling out a long complex form and your tab gets abruptly killed (didn’t happen to me, but it’s plausible).
Instead of just disabling zram, a nice middle ground could be to use zram, but add a swapfile or partition when, even with compression, you run out of memory. Would this be possible to do? If so, how can I configure this?
Hello @gabrc52,
Welcome to the discussion area. Of course you can set up a swap partition, and if it was a new install with BTRFS as the default filesystem, it is relatively easy to do. I believe it may be useful to install the blivet-gui for your partition modifications as it provides more capabilities than the Disks utility. I currently run F33 Silverblue with zram and a swap partition since I have only 8GB, which is somewhat low these days compared to the newer gear that is available.
The way zram is setup, it will use the swap on disk (if it exists) when required due to low ram. Also, you may want to tweak your zram a bit, I think there are ways to tune it’s behavior to suit your needs.
Thanks, I tried it but I’m still getting “read swap header failed”. I’ve tried mkswap before and after these instructions, if it’s after, I get the following output:
mkswap: error: swap area needs to be at least 40 KiB
In this way you have created a subvolume on another subvolume, called “nested”, the problem is that if you create a snapshot of the root lsubolume and then restore the snapshot, you will not find the contents of the “swap” subvolume.
The best way to create a swapfile is the “flat” way, that is to create the subvolume on the toplevel.
As explained by the Btrfs maintainer: https://www.spinics.net/lists/linux-btrfs/msg103213.html
Also explained by Chris Murphy: https://www.spinics.net/lists/linux-btrfs/msg103190.html
These are the steps I take to create the swapfile on Btrfs, no problem with snapshot and restore:
sudo mount -t btrfs /dev/sdYN /mnt
sudo btrfs subvolume create /mnt/swap
sudo chattr +C /mnt/swap
sudo truncate -s 0 /mnt/swap/swapfile
sudo fallocate -l 2000M /mnt/swap/swapfile
sudo chmod 600 /mnt/swap/swapfile
sudo mkswap /mnt/swap/swapfile
sudo umount /mnt
I edit /etc/fstab to mount the subvolume and point the swapfile to the subvolume directory: UUID=yourUUID /swap btrfs noatime,subvol=swap /swap/swapfile none swap defaults 0 0
I only use Btrfs on a testing VM and I’m afraid that my understanding is superficial.
Thus it might be wiser if someone more experienced verifies and clarifies these instructions before their publication.
It’s great that it’s so easy to back out of the zram if desirable, and people were really helpful on this topic. I haven’t noticed any problems, but have a few questions & comments-
Is there any other tuning done for the zram scenario, like swappiness, that would be less optimal for swap on btrfs on SSD?
EDIT Not relevant - NOCOW disables compression. [Is it safe to use btrfs compression for the subvolume hosting the swap file? ]
(Comment) The first method by Vladislav Grigoryev - Btrfs - ArchWiki - worked perfectly for me, and I don’t think I need to use the list of commands to create the swap file and set its attributes. [Edit] The fstab /swap line is necessary, and the one with UUID= may be, if following the commands above. If using the Arch wiki solution (subvolume create /swap), the UUID= line should not be used.
(Comment) Another use case for this - I have 64 GB RAM, but can’t really add more due to limitations of the CPU/motherboard. I sometimes need to run tools that need 70ish GB or more. It’s maybe swap abuse and the wrong tool for the job, but it’s worked well on previous distros, and works well after I made this change.