Code: Select all
zram-config enable-ephemeral
Code: Select all
pi@raspberrypi:~ $ zramctl
NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lz4 900M 4K 76B 4K 4 [SWAP]
/dev/zram1 lz4 300M 26.6M 4.5M 5M 4 /opt/zram/zram1
pi@raspberrypi:~ $ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 30G 2.7G 26G 10% /
devtmpfs 460M 0 460M 0% /dev
tmpfs 464M 8.6M 456M 2% /dev/shm
tmpfs 464M 13M 452M 3% /run
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 464M 0 464M 0% /sys/fs/cgroup
/dev/mmcblk0p1 43M 33M 11M 77% /boot
/dev/zram1 275M 22M 232M 9% /opt/zram/zram1
overlay1 275M 22M 232M 9% /home/pi
tmpfs 93M 0 93M 0% /run/user/1000
Code: Select all
pi@raspberrypi:~ $ zramctl
NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lz4 1000M 138.5M 11.3M 12M 4 /rw
/dev/zram1 lz4 900M 4K 76B 4K 4 [SWAP]
pi@raspberrypi:~ $ df
Filesystem 1K-blocks Used Available Use% Mounted on
devtmpfs 464676 0 464676 0% /dev
tmpfs 94948 64 94884 1% /mnt/run
/dev/mmcblk0p2 30570444 2806144 26472024 10% /ro
/dev/zram0 991512 130280 793648 15% /rw
overlayfs-root 991512 130280 793648 15% /
tmpfs 474724 8776 465948 2% /dev/shm
tmpfs 474724 18260 456464 4% /run
tmpfs 5120 4 5116 1% /run/lock
tmpfs 474724 0 474724 0% /sys/fs/cgroup
/dev/mmcblk0p1 43234 32912 10322 77% /boot
tmpfs 94944 0 94944 0% /run/user/1000
The overlayfs method also allows one to track down which programs tend to slowly flood memory with logs (like systemd, apt status checks, and so on....). I noted widely timed small writes to the same inode can eat through your flash write limit quite quickly. We also looked at a hierarchical priority zram system using several allocations, and found it tended to be less stable over several days. Stretch probably has updated these packages if others are getting more reliable performance, and it may be worth another look.stuartiannaylor wrote: ↑Sun May 05, 2019 6:47 pmIf you use an overlayfs then its only the upper of the merge mount that is readwrite so the only files are ones written to or writing are in ram and fetched from lower by the CoW (copy on write) of the overlayfs.
The OS is not the problem. Other than LXDE, I have pretty much eliminated all writes to the drive by the OS by mounting /var/log, /tmp, and /var/tmp on tmpfs. LXDE does some writes that I think I can pretty much eliminate. The big offender is chromium-browser, which not only writes a lot, but has a lot of large configuration files.HawaiianPi wrote: ↑Sun May 05, 2019 7:02 pmHave you considered using a different OS?
Tiny Core Linux runs entirely from RAM, and there is a Pi version.
I follow some, but definitely not all of that. Again, I will delve more deeply when I have had some sleep. One important thing of which I am not sure:stuartiannaylor wrote: ↑Sun May 05, 2019 6:47 pmIf you are going to enable `zram-config enable-ephemeral` make sure any settings or changes are done before reboot as it is ephemeral on each boot `sudo zram-config disable-ephemeral` and reboot will get you back to normal.
If you use an overlayfs then its only the upper of the merge mount that is readwrite so the only files are ones written to or writing are in ram and fetched from lower by the CoW (copy on write) of the overlayfs.
Problem is with the whole root ro that you need to umount the overlayfs as any further writes could be problematic as the merge down will break the logic between upper working directories and lower that result in the mount.lrhorer wrote: ↑Wed May 08, 2019 8:01 amI follow some, but definitely not all of that. Again, I will delve more deeply when I have had some sleep. One important thing of which I am not sure:stuartiannaylor wrote: ↑Sun May 05, 2019 6:47 pmIf you are going to enable `zram-config enable-ephemeral` make sure any settings or changes are done before reboot as it is ephemeral on each boot `sudo zram-config disable-ephemeral` and reboot will get you back to normal.
If you use an overlayfs then its only the upper of the merge mount that is readwrite so the only files are ones written to or writing are in ram and fetched from lower by the CoW (copy on write) of the overlayfs.
I want to be able to perform upgrades on the fly by updating certain files on the drive. Obviously, these changes cannot be volatile. Is there a way to make some changes permanent?