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 startYes 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)
Hi @mstormi, it does indeed remove that as it deletes the /var/lib/openhab2/tmp directly:
"clean-cache")
[...]
rm -rf "${OPENHAB_USERDATA:?}"/tmp
rm -rf "${OPENHAB_USERDATA:?}"/cache
;;
Being careful with hidden files is one of the reasons why the script deletes the folder and not the contents.
I’ve rewritten part of post #1, giving instructions what to do on OH upgrades so we don’t waste precious memory for the cache.
I’m hesitant for now to automate that (too risky to fail) but I would like to point ZRAM users at it.
@Benjy: My idea is to print a link to this thread when a user runs openhab-cli clean-cache, wdyt?
A little off-topic and German only (use a translator), but see the value that ZRAM gets you for free:
@mstormi At which point, following these steps, the upgrades has to be done? Before, after or somewhere in between? IMO this isn’t really clear from the current description.
Hmmm… I ran openhabian-config to solve a repository error, and then I decided to reinstall zram thorugh the menu.
I then rebooted my RPi3B+ but now zram-config complains about a missing file:
$ sudo systemctl status zram-config
● zram-config.service - zram-config
Loaded: loaded (/etc/systemd/system/zram-config.service; enabled; vendor preset: enabled)
Active: active (exited) since Mon 2020-06-01 11:18:18 CEST; 7s ago
Process: 1916 ExecStart=/usr/local/bin/zram-config start (code=exited, status=0/SUCCESS)
Main PID: 1916 (code=exited, status=0/SUCCESS)
Jun 01 11:18:17 openhab zram-config[1916]: mv: cannot stat '/usr/local/share/zram-config/zram-device-list.new': No such file or directory
Jun 01 11:18:17 openhab zram-config[1916]: mv: cannot stat '/usr/local/share/zram-config/zram-device-list.new': No such file or directory
Jun 01 11:18:17 openhab zram-config[1916]: stat: cannot stat 'stat': No such file or directory
Jun 01 11:18:17 openhab zram-config[1916]: stat: cannot stat 'stat': No such file or directory
Jun 01 11:18:17 openhab zram-config[1916]: stat: cannot stat 'stat': No such file or directory
Jun 01 11:18:17 openhab zram-config[1916]: mv: cannot stat '/usr/local/share/zram-config/zram-device-list.new': No such file or directory
Jun 01 11:18:18 openhab zram-config[1916]: stat: cannot stat 'stat': No such file or directory
Jun 01 11:18:18 openhab zram-config[1916]: stat: cannot stat 'stat': No such file or directory
Jun 01 11:18:18 openhab zram-config[1916]: stat: cannot stat 'stat': No such file or directory
Jun 01 11:18:18 openhab systemd[1]: Started zram-config.
How can I fix this?
Hi Markus,
could you help me understanding the current status of syncing the ZRAM’ed content back to the SD/eMMC/…?
My current understanding is, that the content in the overlaid filesystem in RAM is just sync’ed during graceful shutdown of the system. There is no cyclic “write back” to the lower file system in flash for now.
So is the following still true?
If “yes”, does it mean, the recommended way to permanently store data (e.g. persistence) without shutdown is something like:
If all the above is still the case, are you working on some stuff to have kind of “built-in-sync-mechanism” enabled to permanently store some of the ZRAM directories - at the cost of higher wearing out the flash of course?
yes, yes, no
well no strict need to reboot you can also simply restart zram-config.service.I wouldn’t know if unmounting /var/log works without taking some more system daemons down.