/srv needs to be mounted AFTER ZRAM starts

[mstormi]

else it's pointing to the lower FS (original directories on SD that do not change as all changes are stored in the upper FS in ZRAM only)

[mstormi]

I believe we need to use systemd mount units to enforce proper order first shot at https://github.com/mstormi/openhabian/tree/systemd-zram-mount-order

[lionhe1966]

I followed the instructions of this post on a brand new installation of openhabian: /srv/openhab2-* points to the same directories. Next I will test on my production installation.

[mstormi]

@shutterfreak @BClark09, also @lionhe1966 again would you mind testing my changes and get me feedback ? See https://community.openhab.org/t/srv-in-zram/93422 for install instructions. Thanks.

[mstormi]

@shutterfreak @BClark09 would you mind testing PR #807 ? You need to enable ZRAM for that. Thanks.

[shutterfreak]

@shutterfreak @BClark09 would you mind testing PR #807 ? You need to enable ZRAM for that. Thanks.

I will as soon as I find some time. With the Covid-19 measures in place I have even less time nowadays. But there's a point release of openHAB2 I want to prepare an upgrade for, and then I'll apply PR #807 (and report the results).

[shutterfreak]

@shutterfreak @BClark09 would you mind testing PR #807 ? You need to enable ZRAM for that. Thanks.

I just installed PR #807 and am ready to go.

Current state: openHAB2.5.2-1 with ZRAM enabled.

Which steps should I now run for your test?

[mstormi]

Frankly I don't know how precisely a test suite would need to look like. Just do whatever you usually do while watching out for /srv and other mount points. I would think to check Samba connectivity after stop-start of OH/ZRAM is good test case, and after a reboot (or two), of course. Thanks for your help!

[shutterfreak]

I just applied the procedure detailed in the ZRAM status thread to upgrade openHAB to the latest official point release. Then I rebooted the RPi3B+ which runs openHAB to ensure it also picked up a recent kernel upgrade.

Then I tried to connect to an openHAB SMB share on my RPi, which also works (it always did).

Here are some relevant output snippets after the upgrade (which happened after I manually patched my ZRAM scripts as per PR #807):

[10:30:38] openhabian@openhab:~$ mount | grep -i zr
/dev/mmcblk0p2 on /opt/zram/openhab2.bind type ext4 (rw,noatime)
/dev/zram1 on /opt/zram/zram1 type ext4 (rw,noatime)
overlay1 on /var/lib/openhab2 type overlay (rw,relatime,lowerdir=/opt/zram/openhab2.bind,upperdir=/opt/zram/zram1/upper,workdir=/opt/zram/zram1/workdir,redirect_dir=on)
overlay1 on /srv/openhab2-userdata type overlay (rw,relatime,lowerdir=/opt/zram/openhab2.bind,upperdir=/opt/zram/zram1/upper,workdir=/opt/zram/zram1/workdir,redirect_dir=on)
/dev/mmcblk0p2 on /opt/zram/log.bind type ext4 (rw,noatime)
/dev/zram2 on /opt/zram/zram2 type ext4 (rw,noatime)
overlay2 on /var/log type overlay (rw,relatime,lowerdir=/opt/zram/log.bind,upperdir=/opt/zram/zram2/upper,workdir=/opt/zram/zram2/workdir,redirect_dir=on)

[10:30:45] openhabian@openhab:~$ cat /etc/ztab
# To comment out any line Add new drives with the first collumn providing the drive type and then drive details seperated by tab
# All algorithm in /proc/crypto are supported but only lzo/lz4 have zramctl text strings.
# lz4 is the fastest whilst deflate(zlib) has much better text compression.
# mem_limit is compressed memory limit and will set a hard memory limit for sys admin.
# disk_size is virtual uncompressed size approx 220-450% of mem allocated depending on algorithm and input file.
# Much higher than the compression alg is capable will waste mem as there is an approx 0.1% mem overhead even when empty.
# swap_priority set zram over alternative swap devices.
# page-cluster 0 means tuning to singular pages rather than default 3 which caches 8 for HDD tuning, which can lower latency.
# swappiness 80 due to improved performance of zram allows more usage without effect of raising from default 60.
# Can be up to 100 but will increase process queue on intense load such as boot.
# zram_dir is the directory you wish to hold in zram, the original is moved to a bind mount bind_dir and is synchronised on start/stop and write commands.
# bind_dir is a directory where the original dir will be mounted for sync purposes. Usually in /opt or /var, name optional.
# oldlog_dir will enable logrotation to an off device directory whilst retaining only live logs in zram. Usually in /opt or /var, name optional.
# If you need multiple zram swaps or zram dirs just create another entry in /ect/ztab.
# Stop the service sudo service zram-config stop edit /etc/ztab sudo nano /etc/ztab start the service sudo service zram-config start

# swap  alg mem_limit   disk_size   swap_priority   page-cluster    swappiness
swap    lz4 200M        600M        75      0       90

# dir   alg mem_limit   disk_size   target_dir      bind_dir
dir lz4 200M        600M        /var/lib/openhab2   /openhab2.bind

# log   alg mem_limit   disk_size   target_dir      bind_dir        oldlog_dir
log lzo 150M        500M        /var/log        /log.bind

[mstormi]

got feedback on the forum (link above) some time ago already that patch is alright

[spacemanspiff2007]

I upgraded from a quite old version to the latest stable branch of openhabian and I seem to have this or a related problem. All logs are in /log/openhab2, but /srv/openhab2-logs stays empty.

openhabian@openhab:~$ mount | grep "openhab"
/dev/mmcblk0p2 on /srv/openhab2-logs type ext4 (rw,noatime)
/dev/mmcblk0p2 on /srv/openhab2-sys type ext4 (rw,noatime)
/dev/mmcblk0p2 on /srv/openhab2-conf type ext4 (rw,noatime)
/dev/mmcblk0p2 on /srv/openhab2-userdata type ext4 (rw,noatime)
/dev/mmcblk0p2 on /srv/openhab2-addons type ext4 (rw,noatime)
overlay1 on /var/lib/openhab2/persistence type overlay (rw,relatime,lowerdir=/opt/zram/persistence.bind,upperdir=/opt/zram/zram1/upper,workdir=/opt/zram/zram1/workdir,redirect_dir=on)
overlay1 on /srv/openhab2-userdata/persistence type overlay (rw,relatime,lowerdir=/opt/zram/persistence.bind,upperdir=/opt/zram/zram1/upper,workdir=/opt/zram/zram1/workdir,redirect_dir=on)

Is there anything I can to to reinitialize or reset the zram and mount configuration?

[mstormi]

you could grab the .service and .mount files from a fresh install but frankly I would rather opt to reinstall.

[spacemanspiff2007]

I'll a new 1.5 install - thank you!

[mstormi]

better use 1.6

[spacemanspiff2007]

Hm, I thought about it for a sec but since it's alpha I expected bugs and issues. Nonetheless everything seems to be working now! :+1: