This article is to track and document the current status of the ZRAM feature in openHABian.
I’ll update it if there’s significant news.
What is ZRAM and how does it work ?
The ZRAM config utility for swap, directory & log is an OS enhancement for IoT / maker projects for reducing SD, NAND and eMMC block wear caused by write operations such as logging and persistence in openHAB. It uses compression to minimise precious memory footprint and extremely infrequent write outs and near RAM speed working dirs with memory compression ratios depending on your data and the compression algorithm you choose.
ZRAM is available as an install option in openHABian, use menu option 38 to install or the next (unnumbered) option to uninstall.
ZRAM uses a table in /etc/ztab where any combination and number of ZRAM drives can be created. This implementation uses an OverlayFS mount with ZRAM so that copying data from disk into RAM on boot is not needed. This should allow for quicker boots and larger directories as no complete directory copy is needed. It’s all the lower mount in the OverlayFS.
ZRAM is enabled per default for new openHABian installations.
In an openHABian implementation, swap, /var/log/* and /var/lib/openhab2/persistence are moved into ZRAM. All of that is expendable data, i.e. even if should, things go badly wrong, your openHAB system should keep running. There’s a log in /usr/local/share/zram-config/log/.
We’ve changed this for new openHABian deployments. If you have been using ZRAM for /var/lib/openhab2, you can edit your /etc/ztab to make that change on your existing system, too. Requires to reboot after that.
OverlayFS and mounting
On proper service shutdown (zram-config stop or reboot/shutdown), zram’ed directories (OverlayFS) will be synced to the ‘lower’ filesystem (the same dirname on / filesystem located on default boot medium) and the ‘upper’ filesystem (the part in memory) will be lazily unmounted.
Lazy unmounting means there can still be processes to have open files on this directory. That’s required to run (and keep running) system processes using dirs such as e.g. /var/log.
DON’Ts
-
you must not switch off your openHABian server unless you have properly shut it down.
This has been a requirement unrelated to ZRAM and essentially ever since UNIX exists. Also put it on an Uninterruptable Power Supply (UPS) to safeguard yourself against power outages. -
don’t use
zram-config sync(even if available in your installed version)
This is known to not work in a number of situations and may cause data loss. -
you shouldn’t use ZRAM unless you’re on a SBC (small, “single board” computer such as Raspberry Pis) to run its OS off a flash memory based medium such as SD card or USB stick.
USB sticks are no better or safer than internal SD cards ! - another good reason for ZRAM. -
don’t run ZRAM on machines to have even less than 1GB of RAM such as a RPi Zero.
-
don’t run it on non-SBCs or modified SBCs to run off “safe” media such as SSD or HDD.
Well you can do, but there’s just a negligible benefit in doing that so the cost/risk-to-benefit ratio is bad.
DOs
-
Make use of a backup solution such as Amanda to have daily backups of your zram’ed directories (and all the rest of your system, of course). ZRAM cannot protect against power outages or HW failures.
-
double-check your OH logging settings (
log:getin openHAB console) and make sure it won’t generate more logs than you need. Check also their number and sizes:/var/lib/openhab/etc/log4j2.xml. The accumulated logs need to fit into that ZRAM directory as defined in/etc/ztab(and note there’s system logging to also go there, but by default it’s just a minor amount in comparison to OH logs). -
If (and only if) you have a SBC system with more than 1 GB such as a Raspi 4 with 2,4 or 8 GB or any other SBC with 2 GB or more, you may increase the amount of RAM assigned to ZRAM in
/etc/ztab, starting with/var/lib/openhab2.
Don’t worry ZRAM will not occupy that full maximum amount unless it really needs to. -
you may change the list and size of directories to cache by changing entries in
/etc/ztab.
For example if you consider it to be too risky to run all of/var/lib/openhab2off ZRAM because you want say the Karaf cache to not be on there (as it’s large and pretty much write-once only), you can put a comment sign in front of that line or replace it with 2 lines for/var/lib/openhab2/jsondband …/persistence.
But be aware that on the downside any such change will increase write load on your SD and thus the likelihood of getting hit by wearout.
See GitHub - mstormi/openhabian-zram: zram extensions for openHABian for explanation onztabfields. -
there’s statistics available: run
zramctlwithout options.
For advanced stats, the file/sys/block/zram<id>/mm_stathas all the info you need.
For the complete set of statistics see the kernel docs.
Known issues
You might run into a misbehavior. Please let me know when you do and let me know the relevant details, have you done anything latety which possibly was a trigger ? Edited a .items or .rules file ? Added a thing or binding that might come with a problem ? Changed openHAB version (incl. milestones, snapshot)?
You might run into errors about read-only files(ystem).
If so, issue zramctl and compare the TOTAL column of the ZRAM device for /var/lib/openhab2 (that usually is the 2nd line in the output with /dev/zram1).
If that value is greater or equal to what you have assigned to that share in /etc/ztab, even the compressed data just does not fit in. Assign more space. It’ll only be used by the system if there is a need See OH upgrade procedure.
-
after
systemctl stop zram-configor/usr/local/bin/zram-config stop, a ZRAM device/dev/zramXmight persist (X is a number). You can try removing it viazramctl -r /dev/zramX. If that fails, reboot to get rid of it. Eventuallysystemctl disable openhab2before so it doesn’t start automatically after boot. -
you might see
permission deniedmessages saying the system cannot write to disk into either of these directories or files below because they’re read-only.
This has not been reported by users but occasionally showed up during testing. There’s a lot of potential reasons for this and it is still subject to investigation as to what’s the most likely/most frequent reason to cause this.
ZRAM does never sync to disk unless you stop it (doing so syncs every file that changed into and then unmounts the ZRAM directories). On next start, it’ll not copy these to RAM again so little RAM usage.
Just like on disk, the amount of RAM that ZRAM needs to have available must be larger than the amount of data to store in there but it’s a little more complicated than that because the data also is compressed with a varying compression factor so the exact amount of raw data to fit in is unknown. The amount of memory ZRAM has available is static (defined in /etc/ztab).
Now if something happens to write more changed data to zram’ed directories than there fits into, ‘permission denied’ is (most often) how the system protects itself against even more severe impacts.
You can try deleting zram’ed data but usually you would need to (and the safer method clearly is to) shutdown your system.
