ZRAM status

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?

2 posts were merged into an existing topic: Zram sync

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.

1 Like

10 posts were split to a new topic: No space left on ZRAM

7 posts were split to a new topic: /srv in ZRAM

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.

Understood :wink:

I understand it that way, that this would sync the content too (without rebooting) but is not intended for that purpose and may bring some additional risk and cannot be recommended for a regular task (e.g. by cron or systemd-timer) - right?

Wouldn’t it be possible to regularly rsync instead between some of the overlay and the underlay directories similar to how ASD it does (“anything-sync-daemon”)?

Taken from https://wiki.archlinux.org/index.php/Anything-sync-daemon :

anything-sync-daemon (asd) is a tiny pseudo-daemon designed to manage user specified directories referred to as sync targets from here on out, in tmpfs and to periodically sync them back to the physical disc (HDD/SSD). This is accomplished via a symlinking step and an innovative use of rsync to maintain synchronization between a tmpfs copy and media-bound backups. Additionally, asd features several crash recovery features.

Well the main problem is I didn’t write the original code so I’m not aware of all the dependencies there may be, and ZRAM is an OverlayFS that is unlike decoupled systems where you can apply rsync/asd/whatever.
I already implemented the “sync” option to execute what it otherwise does on “stop” but ran into some issues by the time I did. Those still may or may no longer exist but I haven’t found the time to follow up.
Feel free to experiment with that and let me know how it works
But use a test system - no warranties.

Great work @mstormi! :smiley:

Only in OpenHABian I take it, correct? Not regular vanilla self-installed (from Debian repos) OpenHAB, amirite?

<offtopic

Every time I read something like this, it re-affirms (to me, anyway) that I made the right decision in keeping all my configs purely in text files this time around. :wink:

</offtopic

Not sure if that is the default in Raspbian or not, but I know it is in Armbian (which is what I use).

Which makes me wonder how the two might interact. Seems this is just for OpenHABian distro though, not OpenHAB itself if I am understanding correctly.

Yes of course.

OpenHABian on Armbian ? Duh, dunno. It might work but we don’t test that so you need to be prepared to hit issues.
But why complicate things and risk availability ? Run openHABian on a supported OS instead, Raspbian and Debian these are. If you want to stick with Armbian by all means, it also has ZRAM.

Oh no, I run regular OpenHAB on Armbian, not OpenHABian. Both of the latter I would consider as “distributions” essentially. In other words “one or the other.”

So in other words, if this change only affects OpenHABian (as you now confirmed) it doesn’t affect me at all.

Sorry if I was unclear!

12 posts were split to a new topic: ZRAM issues

I have the same lines on the log, but zram works anyway.

Didn’t you put the latest file revision of zram-config in place ?

Last month I installed OpenHab 2.5.4 from scratch starting from a fresh standard openhabian image and porting all bindings configurations one by one: therefore I am using standard zram settings now. I then upgraded to 2.5.5 (and I had some issue of standard bindings not being loaded, possibly related to the fact that my openhab installation take a significant amount of memory, but after a couple of openhab restarts and raspberry reboots everything came back to normal)

I’m referring to the zram-config script, latest version should not exhibit that behavior.
If it still does please open a GitHub issue there to track.