highvoltage/zram-tools

Scripts for managing zram

zram-tools's Issues

Please add ability to mount /tmp (and simillar temporary folders) on zram device, like zram-config

I've noticed, that zram is a very good solution for /tmp (and maybe other temporary folders, like /var/crash/). There is a zram-config project, which contains an ability to mount /tmp on zram device, see https://git.launchpad.net/~eugenesan/+git/zram-config

Please use patches from zram-config for /tmp mounting. All these improvements already commided to zram-config branch in 2016 by Eugene San, see https://git.launchpad.net/~eugenesan/+git/zram-config
* Rework scripts to utilize built-in zram multi cpu support
* Add support for /tmp mounting on zram device
* Introduce defaults file for setting parameters
I successfully use zram-config with these improvements since 2016 in hundreds computers with Ubuntu and Baltix GNU/Linux distributions!
For more info look at this bugreport: https://launchpad.net/ubuntu/+source/zram-config/+bug/1548424 (and https://bugs.debian.org/930412 )

zram-tools uses outdated by 7 years approach in setting up zram thread count

zram module has max_comp_streams property since around 2011, and nowadays it is (at least on x86/amd64) is autodetected to match the CPU core count.
Setting up multiple zram devices is inefficient even if each one is set to use only one compression stream, but with default settings it will end up using number of threads equal to square of the CPU core count (4 on dual-core, 16 on quad-core, etc.)
Note that I don't have access to any ARM boards or other supported by Debian platforms, so I cannot verify whether zram module has the same max_comp_streams behavior there.
Also note that a more lightweight approach to setting up zram could use udev rule instead, e.g. this is what I've been using on my systems:

KERNEL=="zram0", SUBSYSTEM=="block", DRIVER=="", ACTION=="add", ATTR{initstate}=="0", PROGRAM="/bin/sh -c 'echo $(($(LANG=C free -k | grep -e "^Mem:" | sed -e "s/^Mem: *//" -e "s/ .//")*2))KiB'", ATTR{disksize}="$result", RUN+="/sbin/mkswap $env{DEVNAME}", TAG+="systemd"

Can we cut a release please?

Give Debian's old package which fails to use more than one core (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917643) it would be great to cut a new release, so that Debian can pick up the fixes that have happened on April 2, 2019.