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.
2 Likes
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.
1 Like
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
1 Like
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.
2 Likes
Oh come on Rich. You’re right to some extent but that does not entitle you to make that first claim.
We all ourselves do this every day: we recommend OH, milestones and other tools to and for use by non-expert users despite knowing well they aren’t 100% either. Just browse the openhab-* issue lists on GitHub.I don’t even know how long they are right now.
If we ever had been developing and deploying like that we wouldn’t have a working OH today. Your remarks on docs are valid but although I actually didn’t really have the time to today I felt pressurized to quickly put that stuff up so here you are.
I wasn’t aware that I wasn’t entitled to my own opinions. I’ll keep that in mind.
The difference between recommending a milestone release or an updated bindings and this though is:
-
if something goes wrong it’s easy to roll back without starting over from scratch; as far as I can tell there is no way to roll back after you move to zram short of a reinstall of openHABian from scratch
-
there is little to no risk of losing configuration data, especially if one doesn’t have the expertise to know that running
sudo rebootmeans losing all your changes since the last reboot but runningsudo shutdown -rwill save all your changes -
zram guarantees the loss of data (logs at a minimum) in cases where the machine loses power.
I argue that in this case it’s different from recommending different versions of OH because of the risk of loss of data *under normal operating conditions." It should have a higher bar to pass before recommending it to users who can not understand the draw backs or limitations nor the risks to their data.
But that’s my opinion which I’m apparently not entitled to.
Nope, you can also uninstall ZRAM via menu, getting you back to where you would have been without.
zram is only activated on /var/log and /var/lib/openhab2, the latter of which stores just a minor part of the config.
And if you take proper precaution (UPS, backup) - and the explicit use of beta SW will make you even more aware of the need for this than if you run release or milestone code -, the risk of really losing that config data isn’t larger than on non-zram systems. Let alone that it isn’t fair to compare say a new binding to zram w.r.t. data loss risk. It’s a little like arguing in favor of zram that it is better because it is 100% compatible with any OH functionality and device while that new binding initially still has some issues. But of course that simply only because zram doesn’t touch that area.
Ok we can have an argument over what sort of specialized knowledge we can expect from a user but I already conceded that docs were weak and went to deliver improved ones.
If you did compare apples to apples, i.e. beta SW and docs quality to other beta SW, I’d say this is rather more than you get on other feature’s very first release.
Which still is the best possible result under the conditions to apply (SBC with no reliable storage medium available). And logs and even persistence data is expendable data only.