I wouldn’t care to reduce processes to do more or less one-time writing which is what most demon processes do w.r.t their PID… quite some risk to break things and no real benefit.
If you’re really seeing “lots of” writes to that dir, something’s wrong (permanent startup loop ?) and you should find out what it is instead.
Great let me know what you find as I have been doing this for a long time on multiple projects not just Openhab with great results.
Sorry no idea, best asked on the Raspbian forum perhaps… But yes it is safe in the sense you can not damage your hardware in any way and if you have a backup of the SD cards contents it is very easy to reverse, so go for it and try it, that is the best way to learn. Linux has for years allowed itself to be loaded into RAM, non persistant USB loads, LIVECD’s, the list can go on not to mention every professional project that can not accept flash corruption…
This link may interest you as it mentions the lock files with a solution, some of what is written in that article I dont agree on for example data corruption does not damage the drive requiring you to throw it away…
It is hard to predict what a programmer does in a binding or other type of addon so your behaviour or any other type of extra writes could be from what is being done in an addon. Worth checking into to see if it is an issue as Markus is indicating or perhaps a binding is doing it. Have fun playing.
I was reading the whole discussion.
By testing my openhabian. I found only the logs to be really active in Writting, most of other files use read.
I did Move the logs on a remote location. I covered this on another thread as HOW TO. But only for openhab logs. not system.
By testing my system, the most active location after logs was my persistence db, everything else was more or less read only.
What I did for these was:
- Mount on /mnt an external USB flash drive
- I created folders inside the mnt/ (persistence, logs)
- I stopped openhab2 and rsynced the /var/log to /mnt/log (the same for /var/lib/openhab2/persistence to /mnt/peristence).
- Instead of Symlinks! I used the mount command and bound some folders to relocate writing
My /etc/FSTAB:
proc /proc proc defaults 0 0
PARTUUID=578b7f5f-01 /boot vfat defaults 0 2
PARTUUID=578b7f5f-02 / ext4 defaults,nodiratime,noatime 0 1
UUID=“039c7f8a-b8d6-4428-8962-36555f669175” /mnt ext4 defaults,nodiratime,noatime 0 0/mnt/log /var/log none defaults,bind 0 0
/mnt/persistence /var/lib/openhab2/persistence none defaults,bind 0 0/usr/share/openhab2 /srv/openhab2-sys none bind 0 0
/etc/openhab2 /srv/openhab2-conf none bind 0 0
/var/lib/openhab2 /srv/openhab2-userdata none bind 0 0
/var/log/openhab2 /srv/openhab2-logs none bind 0 0
/usr/share/openhab2/addons /srv/openhab2-addons none bind 0 0
This way 99,9% of my writes has moved to /mnt (external flash thumb)
Next step is to use overlayfs to force all changes to move to USB thumb drive. And not on
This way I can mount the sdcard as readonly.
I also do keep all my /etc/openhab2 on a remote git server (therefore some of my config is there. Use Borgbackup (opensource) to backup specific folders on remote location.
Also this is my Inotify collection for 30 minutes at whole system: total access modify create delete filename223514 210806 12708 0 - Pastebin.com
1 Like
Be aware that USB flash drives use the exact same technology as SD cards so if your persistence is storing important data, it too is at risk of wearing out and corruption.
I have no important data, but also Nightly backups if no io issues exist.
I also plan to test the new USB SSD from sandisk for important stuff
Newer writes that have started in my Ubuntu based setup since this guide was first written:
/run/samba/msg.lock/ (multiple files)
/var/lib/mosquitto/ (mosquitto.db and mosquitto.db.new)
/var/lib/ntp/ (ntp.drift.TEMP and ntp.drift)
/var/lib/openhab2/jsondb/org.eclipse.smarthome.config.discovery.DiscoveryResult.json
/var/lib/openhab2/jsondb/backup/ (multiple files)
Since I am no longer using Openhabian I can’t confirm or test any ‘fixes’ for them. I now use my install script for my Odroid C2 found here to shut down the writes and this is done in a number of ways. You can open the install script in a text editor and read how I handle these files as I test and implement a work around to stop the writes.
Thanks for this post. By following this I was able to transfer my logging and persistance to an external flash drive. However initially mosquitto was not working. But after creating a “mosquitto” folder in log folder it started working.
It may not be worth all of the trouble now that SanDisk > Western Digital is now making MicroSD cards exactly for HDD replacement applications, including fast, high-endurance SLC, plus a wear-leveling controller all in one MicroSD package. About $25 per 16 GB.
Promises to be making. Most cards already do wear-levelling BTW.
If you want to rely in that, feel free.
For everybody else there’s now ZRAM available in openHABian.
There’s a lot more to HDD-class flash storage than Wear leveling, e.g. SLC among others differences in controller logic. I consider this cheap marginal improvement in availability no matter your setup.
There are better options out there. OpenHabian if you have RPi … while if you are on Odroid or something similar, check Armbian | openHAB
All reasonable SD card optimisations comes out of the box, ZRAM logging, delayed writing … are present in the system for around 8 years now. For most demanding cases system can also be switched to fully (virtual/memory file system) read only mode (Ubuntu variants) which means absolutely no writings (damaging) to the SD card. Optimisations boost up the system since it doesn’t use slow media so much and also prolong their life.
SD cards were improved in past decade, but they eventually die. Also most expensive ones.
Panasonic also makes industrial cards. See https://na.industrial.panasonic.com/products/storage-media/industrial-sd-cards/lineup/industrial-grade-2d-nand
They won’t last forever (just like you and me 
), but they might be helpful for some users.
It is interesting that people always concentrate on card wear out and miss a very important piece of having a stable setup. That is if the power fails in the middle of writing a block of data it can corrupt the entire block which can contain operating system files when the write was only for a log file. It is like playing Russian roulette when the power fails. If you delay the writes it only changes the odds. Stopping the writes is how all devices like routers work that still use flash and just keep on working.
If you use a UPS it does not solve the issue fully but it does help until the battery goes flat.
I have a pi clone setup on my tv that gets the power cut every time the tv is turned on and off, it is still working years later despite the thousands of dirty shutdowns.
Spending more on a flash drive does not solve the issue of corruption.
This thread is now very old and outdated as I don’t use openhabian I have no idea how often it writes, you can use the methods in this thread to find out, led flashing on your Pi, the Linux command to watch in real-time the writes.
The Panasonic does mention “power fail robustness”. Not sure exactly what that does, but it might help.
I use a battery backup with the apcupsd daemon to shut down the system cleanly when the battery runs out. That works very well.
ZRAM in openHABian uses OverlayFS since OH cache is written at OH start and it’s huge (300+ MB) so we don’t want to keep that in a Pi’s RAM.
@mstormi
I should write a big THANK YOU for having put ZRAM and any other features into openhabian to address this. Any improvement is a step in the right direction and helps to stop people blaming Openhab for being unstable when that is not the case.
Yes I see that as the biggest issue.
- UPS drains completely and the power is lost, luckily we escaped corruption when this happened.
- The power comes back on with a flat UPS and the system powers back on and then cuts in and out 30 times over the next 10 minutes. This happens a few times a year at my place.
- This time when Linux/Openhab is booting it is writing like crazy and the odds are very high that corruption will occur. We don’t escape corruption this time and the UPS has failed to help.
- We have an automated backup system that then backs up this corrupted data.
- People then complain that they have worn out 3 cards and/or Openhab is unstable when there is nothing wrong with the card and it can still be used after a re-image.
There are ways to setup a UPS to stop the above happening.
Okay, I’ll bite. How do you do that? I have my UPS set to turn off at 50% battery, so it would likely survive the scenario you list as it could cover the next 10 minutes of on/off, but if that happened to be longer, my system would try to shutdown and restart frequently as well. It would be interesting if the UPS had some sort of turn on level so it wouldn’t turn on until the battery charge was at least at a specific level. Then we could have some hysteresis. But I don’t see that in the cheap UPS units. And you have made me wonder what the apcupsd software will do if the system starts up and the battery is already too low. Presumably it starts an immediate shutdown, but I don’t see anything documented about it. It appears that most of the software assumes a power outage followed by good power with no additional outages, but that isn’t what happens in my area.
There are plenty of articles about this topic which is not new or unique to Openhab, a quick google will return many written by people that are smarter then me. I only wish to get people thinking about the issue instead of blaming Openhab or flash based cards. If you know about it then you can put a plan into action to deal with the issue. A UPS helps reduce the risk and by having one you are smart.
Same here, my UPS logs at least 40 issues a week with the local power. I choose to accept some risk and to use backups by keeping a uSD card that is ready to go and can be swapped out by anyone. This brings up the second point I try to push and that is having a good backup that is not made from potentially a corrupted source.
SSD’s usually have extra power stored for this exact reason and auto sensing to know the power has failed and they can complete the write they are performing before the power is lost without corrupting the rest of the data that was in the same block. The price of SSD is now very low.
This good points mainly fit to the openHAB 2 with PI. Are there some tutorial for a general installation?
Read about ZRAM and the documentation for this feature in the openhabian docs.