To properly power off the RPi you should use sudo shutdown -h (halt the system) instead of sudo shutdown -r (reboot the system).
@mstormi
Just some follow up questions in a proper thread:
- Does this has been tested on RPI 4?
- Are there any downside of using ZRAM? Like using more CPU or anything like this…
It works in openHABian 1.5 which is buster based. The Pi model does not make a difference.
Read the post #1
I’ve started to play with this some more. It seems to be stable enough to rely upon on a remote machine.
It is probably worth mentioning that if you use openhab-cli backup, you will want to move the zip files out of /var/lib/openhab2/backups. There’s no reason to have these files loaded into zram.
Great, thanks. An upcoming openHABian PR will unmark it from being beta. No not exclusively because of this statement of yours, but thanks nevertheless.
Right. @benjy could you please take care of that ?
Dunno which repo openhab-cli belongs to else would have filed an issue there.
I already implemented a similar thing with openHAB log files:
In essence, you’ll need to schedule a cron job to relocate the backup files to another location outside the control of ZRAM, e.g. somewhere in /home/openhabian).
openhab-cli provides the shortcut for the distro’s backup script, (which has a default directory of ${OPENHAB_USERDATA}/backups). But that’s only if a path isn’t specified.
You can also change the default directory by setting ${OPENHAB_BACKUPS} in the /etc/defaults/openhab2 file. I’d reccomend doing this during the zram setup stage and notifying the user of the change.
1 Like
@mstormi, does zram sync after an apt update changes the contents of the /var/lib/openhab2 directory? I’m not entirely convinced that the whole folder should be included.
Well changes are active but not synced to disk/SD. No you cannot force syncs with the fs online so it’s just “virtual” changes until you shutdown (w/ sync).
I agree we could spend some more thoughts on what to include and what not, but note it’s not possible to exclude subdirs if the upper dir is included so that sort of forces some bundling we eventually wouldn’t want to have.
I think the safest approach would be to check if zram is active and temporarily disable it during the openHAB upgrade process.
Only including cache and tmp seems like the way to go then. These are the only folders with frequent access AFAIK. Many bad things can happen to openHAB if the other folders were to be desynced with the runtime and it seems weird to place files for configuration in memory only which you’d usually expect to persist.
jsonDB already has an adjustable write delay to prevent too many writes, which can be changed in the paperUI/conf settings.
MapDB and rrd4j also save their files to userdata.
Certain addons will create a folder too in userdata and how frequently it writes to them will vary from binding to binding. For example, zwave and zigbee has a folder that gets written to rarely. MQTT and the Moquette broker add-on on-the-other-hand I could see needing to write quite frequently depending on how often messages are sent and how many are retained and such.
Karaf cache, jsondb and persistence exactly are those write intensive parts of OH why I chose to define ztab like it is now. I’d be happy to be more selective in defining what’s to be zram’ed but the problem with more ZRAM dirs is to waste precious memory, like in excessive disk partitioning. I think we would need to re-sort the OH subdir structure first. Maybe moving it all to one dir and to put links is sufficient.
As a systemic approach (albeit before ZRAM) I actually once suggested a change to openHABian to place all (changing) OH data into a common “volatile” dir with “essential” and “expendable” subdirs.
Config and persistence would be placed below “essential” and that would be mapped to some reliable medium (SSD,HDD? nowadays ZRAM ?). Logs would be below “expendable” and that would be mapped to RAM or some none-reliable medium such as an USB stick.
But at that time, noone was willing to take that ball. And the risk. Frankly, I felt ZRAM to already be a pretty risky step to take (got a reputation to lose, that is 
), let alone that it had the potential to devastate many people’s setups.
From my prospective I absolutely see the benefit of ZRAM and your implentation of it in openHABian. I’ve been running my home’s openHAB instance on the the same 128GB SD card for a few years now on Raspbian (now on a Pi 4), but that’s just with all of /var/log set on tmpfs.
As @rlkoshak alluded to, I probably don’t have many addons that are taking “advantage” of their own space within userdata so I’m interested in worst case. When I get the time I’ll run
inotifywait -m -r /var/lib/openhab2
With a few different setups to see how frequent the writing is.
Hi Markus, sounds really good this ZRAM! As I suffered from flash memory wear issues I am going to try it out.
There is a lot of information in this post. I would suggest to condense it a bit and place the most relevant part right in the beginning. Here some improve suggestions that it is easier to understand for all the people not so deep in the topic.
Blockquote
Rebooting … the former recommendation not to userebootorhaltis obsolete because all current OS seem to behave right. But nothing in life is 100% safe and it’s not wrong in principle so I keep it in the ‘known issues’ section for reference.
Reboot your system always with sudo reboot or sudo halt. The former recommendation not to use this commands is meanwhile obsolete.
Blockquote
you must not switch off your openHABian server unless you have properly shut it down.
While this has been a requirement unrelated to ZRAM and essentially ever since UNIX exists, it’s amazing how many people still do this today. Put it on a UPS to safeguard it from power outages.
Switch off your system always with sudo shutdown -h. This ensures a proper shutdown and avoids the risk of a corrupted system. If you suffer from power outages it is highly recommended to us an UPS (Uninterruptible Power Supply).
I am missing a short section how to install:
How to Install
Upgrade your openhab to V2.5 Milestone 5 or newer. ZRAM can be installed from the Openhabian Configuration Tool. Choose “System Settings - Use ZRAM”. Reboot your system after installation.
Best
Thomas
Am I correct in thinking that anyone using ZRAM should always use the process you defined in Post #1 to clean the cache? And if so, does that make the typical three-step method dangerous?
openhab-cli stopopenhab-cli clean-cacheopenhab-cli start
Yes on OH upgrades you should use that method (BTW I reworked that).
There’s a lot of copying going on when you stop ZRAM and when you start OH.
Frankly I don’t know if your 3 steps are dangerous, but I often ran into “read only” trouble when I didn’t stop ZRAM first.
Hi @Benjy ,
could you please double-check that an openhab-cli clean-cache actually removes /var/lib/openhab2/tmp/.*, too ? Note the dot which does not match * patterns.
Stumbled across as if the size of /var/lib/openhab2 outgrows what’s configured in /etc/ztab we run into “read-only” problems.
thanks (didn’t find the right Github place right away for this msg so posted here)