( Openhabian, Raspberrypi 2)
Hey,
I just found out the zram feature and I like the idea to use the ram for logs.
But I’m a bit confused about the function. And I can’t find lot of informations about that yet.
Is there any cronjob or s.th. like that to save the data to the sd-card again from time to time?
It obviously needs this for checking the logs after a crash, but where is the option to configure this?
I would appreciate if anyone give some informations 
I believe it only saves to the SD card upon a proper shutdown and does not do it periodically.
On a system crash (i.e. OS crash), the logs will be lost.
There is an menu option in the openhabian-config program. It installs zram, but what it exactly do, I don’t know.
It moves openhab and it’s logging to run out of RAM instead of off of the SD card. this eliminates the issues with wearing out SD cards because of excessive writes, but it means that if you pull the power all of that data gets lost.
If that’s the case then what’s the difference with just mount the log directory to a tmpfs? That’ll be also lost when the power is off.
If you don’t count the RAM savings main differences are that it’ll work on existing directories (like persistence) which won’t get lost (reset to start at worst) and on proper treatment (shutdown) it will NOT lose the data but sync instead. You can also sync manually.
is it already working? last time I checked it was worked just once and then not.
as well is fair to say, if you do any upgrade/install etc. and you won’t perform “proper” shutdown, everything will be lost at next boot, not only logs. System will return to last harddrive state it has got.
especially between releases this will mangle your OH instalation big time.
You’re talking about the online sync extension which is not available yet in openhabian.
I meant to stop zram/unmount the disk.
How does it work?
I just rebooted after one week and lost all my logs.
Luckly my rrd files were up-to-date 
That shouldn’t happen if you do a proper reboot such as “shutdown -r” to properly stop all running services such as zram.
You can manually call zram service script with the stop parameter. That’ll sync+unmount the zram disks.
Online "Sync"ing is not supported yet (not verified to work).
This is a potential problem with this implementation. “You are doing it wrong” is rarely the right answer when the same problem shows up over and over again. Especially if the only way to do it right is to know and understand something as arcane as the difference between reboot and shutdown -r, something that, based on a quick poll of heavy Linux users I know, only one out of 8 was aware that there even is a difference. It doesn’t seem fair to blame the user for not doing it “properly” when knowledge that there is a proper way is not general knowledge.
And the answer of “you should never reboot or shutdown” is also not feasible. There will be times, rare though they may be, where a reboot or shutdown will be required.
And we still have the problem of power loss. When running headless, no matter the risk, there will be times where the only choice is to pull the power, e.g. when the machine is otherwise frozen or unreachable. I’m not saying that zram should be able to handle that problem, but to insist that it would never happen is not reasonable. There should be at a minimum good documentation to explain this (zram is not mentioned at all in the OH docs nor in the openhabian README.
I did not know the difference.
Just found out that in Buster none of them will work anyway. (fully switch to systemctl)
so for now I use
sudo shutdown -r
and in future with buster
systemctl reboot
is this the right way then?
Tanks to @rlkoshak for you detailed answer 
You are right with your complain about the doc, but I’m very happy that zram even exist. So thanks to @mstormi for your support and time on this thread as well!
I’m just stating the facts. I’m not blaming anyone for not knowing this. If it comes across I do please apologize and attribute this to the fact that I’m not a native speaker.
And on the other hand I feel it isn’t fair either to expect a sudden 100% solution to a problem which has been heavily plagueing many users over the years, and to speak frankly, doing so is a little naive, too.
Note the feature is marked to be beta.
I agree documentation should be improved (or created as in fact it is non-existent although that all by itself should already be a word of warning, shouldn’t it ? Then again, I in fact did initially contribute a little more than that but seems someone copy-edited that out).
But as you know well for yourself docs are tedious work and even more so on beta features where we don’t have experiences yet and a moving target.
And even with docs in place, there’s only few people to really read them and even less you can convince to stop doing harmful things on Linux (reboot) that they have been doing ever since.
You have to start somewhere and this is the very first implementation and all of us, including me, need to make and collect our experiences here. I myself didn’t think of that reboot thing until it was mentioned here.
I was hoping to get the online sync to work soon which would resolve that problem for the most part but I currently guess we’re not getting there anytime soon so I’ll have to put some works into the docs first. Maybe add a safety disclaimer to the install menu.
Should be fine AFAIK.
Duh, haven’t seen that variant yet. I’d guess it takes care of stopping services, too, as it’s a frontend command to systemd. But I don’t know, just guessing.
If it’s not 100%, then it shouldn’t be promoted for use, especially by non-technical users and there should be docs and warnings saying so. It’s a radical rethinking about how OH is deployed and even a lot of experienced users are not knowledgeable enough to understand the tradeoffs and limitations of running in zram. I’d argue the feature is at best experimental at this point.
I don’t recall seeing anything in the too itself indicating it is beta.
Since most users will not look beyond the tool, sadly I’m not sure there lack of docs would be sufficient. In my experience, having docs are mostly used by many users only after they run into problems.
That might be enough. If the tool says “danger, do not proceed unless you already know what you are doing” it might be enough of a discouragement.
I can see lots of benefits using zram. However I think the general recommendation to avoid sdcard wear out should be to use an ssd via usb. Zram is complex and imo it will be easier for most users to use external storage.
Anyway it’s definitely a very attractive feature, zram, especially with the rpi4 (4g) where you have an abundance with ram.
Regards s
No, that definitely is not easier (or to be recommended in any way).
Yes zram is complex but making use of it is not (well maybe now in beta it still is but of course that’s what we’re busy working to reduce). The ultimate target of openHABian is to hide all that complexity from OH users by wrapping that in menus and automation.
The majority of (and targeted) users of openHABian have NO Linux experience.
You musn’t expect them to be able to migrate their system to boot from external medium, let alone exposing users to all the things that can go wrong along that process.
and
I think it easier to use an external storage compared to zram. I might be the only one, but judging from the number of issues with zram that I read, I have a hard time believing that zram would be a lot easier to everyone. And I do think you are jumping to conclusions a bit too quickly.
I guess time will tell. Anyway, I didn’t come to bash on zram, like I said it’s an amazing feature and I recognize all effort you put into it.
Regards S
Well if you know how to do that then you’re part of the minority. Just as am I and most to contribute to this thread. I assume you’re also striving to understand the implementation because a move to external storage wouldn’t work if you didn’t understand the steps there.
But using zram works without (well, will work when we’re out of beta one day).
openHABian users don’t need to understand how zram works, they just need to enable it in the menu.