Unless Linux gets rid of LZO compression, I don’t see that there’s much that can slip (and, even if that happened, the user would just have to edit one line in the systemd-zram.service file to change to another compression algorithm).
I wasn’t criticising zram-generator - I tried it myself but my ADHD-addled brain must have missed a set-up step somewhere as it wouldn’t start, so I went with an alternative (systemd-zram) that required no setting-up (apart from enabling/starting the service) & instantly did the job for me. And, at the moment, it is working fine:
free --human
total used free shared buff/cache available
Mem: 28Gi 5.0Gi 19Gi 592Mi 4.7Gi 23Gi
Swap: 21Gi 82Mi 21Gi
I still had zswap in my mind after seeing it briefly in the inxi output. I dismissed soon after and decided to speed things along a little, as nobody seemed to be making much progress.
Yes, I thought so too; especially considering not much else seemed to be in OPs best interest. However, thanks for highlighting zram as a possible alternative. I’m sure others reading might be inspired, as the use of systemd units is slowly beginning to gain some traction for various tasks.
Unfortunately, the dynamic nature of zram isn’t ideal when taking into consideration hibernation, as @Nachlese noted earlier. The OP hasn’t reacted to hibernation when it was mentioned several times, but has allowed swap space for it, so I presume needs have been met.
I was considering using zram myself for a side project, using a 250GiB SSD, where available space actually matters.
