I can’t think of any reason why it wouldn’t work. 8 GB would be way overkill. You could probably make due with 2 GB (my current install is sitting at 2.6 GB but 1.7 GB of that is my .git folder and another 500 MB of that are OH logs, I have a couple of bindings configured with trace logging level so I’m generating a lot of logs right now).
Obviously YMMV but I would expect 2-3 GB would give most users plenty of room to expand.
Of course there may be limitations but I suspect you are aware. Since you’d be running from a tempfs, the entire file system will get wiped on a reboot. So your OH would not be able to persist anything that you need to preserve from one boot to the next (I’m not talking about OH Persistence which you can run a traditional external database in the traditional way for that). You will also need to modify the start script (I’m assuming a .service file) to copy OH and all it’s configs every time you reboot. If you don’t include userdata/cache and userdata/tmp this also means that OH will have to reinstall all of your bindings every time you reboot.
But in general, whether the file system is a tempfs or on physical media is transparent to OH (or any other program you want to run). But those programs will not expect the file system to be wiped on every reboot so you need to think about what gets written to disk.
I’m not sure what you would gain by doing this though. Except for logging and persistence, OH is a pretty disk read/write light application. I suppose it could restart faster (but not the first start after a boot in which case it will start much more slowly).
I was recently watching rules gets triggered with bit of lag and cpu seems to be almost always idling (not really sure if its because config 53, delay rules - which I believe is only during boot) so I was thinking it might improve overall performance as ram is way faster than disk.
As I said it’s more about education myself what and how can be done.
Is there any list of folders which are essential for OH to keep? (besides /etc/openhab2/)
eg. installed addons, configuration made in paperUI and so on
Only if the bottleneck is disk IO. Before going through a lot of effort to move OH to a tmpfs, maybe spend a little time proving that is in fact the source of your problem.
I’d be very surprised this is your problem. Once Rules are loaded into memory at OH start time they remain in memory. Disk IO can’t cause the lag. Moving to a tmpfs will improve how quickly those Rules can be loaded in the first place, not in how they run.
If it’s about SD or other flash wearout then check out zram implementation in latest openHABian 1.5.
It’s selectively doing that for a list of directories you can specify.
Effectively it’s not required (and not beneficial) to move everything into RAM, it’s sufficient to move those dirs (and swap !) into ram that would otherwise write to disk which is those specified in /etc/ztab (these you can extend if you want to).
If that’s your rationale this is likely due to compiled rules being garbage collected. Increase -Xms java parameter to 250m or more. Quadruple that number if you run on 64bit x86.
Yes that’s only changing the load order on OH startup.
i don’t have old install, actually it’s like 2days old on rpi 3b+ and i really hate firemotd when loggin in to ssh and have to wait couple of seconds till I can actually write something to shell.
I’m not hating habian, just using something else. If there will be an easy way how to disable firemotd completely, will do as first thing I can when installing habian
Till now I don’t really see any differencies between running habian or anything else what one likes.
I have rpi3b+ and rpi3b and rpi4 for testing running habian or dietpi and must say they act like twins
I think it’s just a line in your .profile or .bashrc.
I tend to keep it up to date and while I like it, it is pretty slow.
When everything works, they work the same. When something stops working we won’t be able to help much is Markus’s point. If you know what you are doing there’s no problem as you should be able to stand on your own. but if you need help or don’t know what you are doing, running dietPi will greatly hinder our ability to help if something goes south.
I only have one install from openHABian and manual installs on my other machines. Even on beefy VMs (compared to RPi) it takes one to two seconds for FireMotD to let me have my prompt. It’s worse on the RPi 1s and 0Ws. I pull and rebuild from github FireMotD a couple times a week (it’s part of my update Ansible playbooks).
You might be right on this, actually it’s probably too much effort with little or none effect, it came to my mind when I’m playing with different scenarios/setups/systems/platforms and OH together.
Just something to talk about really
to disable appearence probably yes, but it’s doing some stuff after apt update as well which seems unnecessary for me
Have to figure out how to remove it if possible
I don’t even know why I’m so bothered with it honestly, but for some reason it’s like red flag
I didn’t study the makefile to see how thorough the uninstall is but that should remove the cron jobs and entries in the shell init files. Test to see if you are happy after running that and if so, delete /opt/FireMotD.