So in a normal steady state system, your machine is writing 187 kBytes/s, whereas mine is 40 kBytes/s. Considering I also run influxdb on my Pi, I find this a little strange.
Do you experience any SDCard failures?
I suspect we have different message profiles. Currently I have a bunch of devices sending meter readings at a high rate into HA with full event logging. Each reading is around 5-6 messages (current, voltage, power, energy, …) and these are all adding up to a ton of database writes. Whereas you may (?) have a less “chatty” network albeit with two sets of writes (HA and InfluxDb). I have Influx running on a separate server so the RPi isn’t having to carry that load as well. So the numbers could be right.
For me, SD card issues have generally had more to do with unexpected power outages leaving the sd card in a corrupt state rather than writes wearing out the card. I had a power outage recently that messed things up and decided to move to an RPi3 with a USB flash drive mounted instead. Not sure it will make a difference but will see. Best is a sound backup strategy of course. 8)
1 Like
sound backup? 
You gotta love the global community. I re-read that sentence and did smile at how it could be misinterpreted! Of course, “sound” is Irish for “robust”. In my case, backup strategy is an emergency crate of Guinness to help me mourn the lost data!
2 Likes
I live Guiness and Ireland! By the “sound backup” I imagined my old Atari or ZX Spectrum connected to tape recorder and making backups. Yep and now it’s the time to open my Budweiser Budvar, cheers from Czech!
I’ve seen similar problems, already two cards burned by Hass in about 1.5 year.
From what I’ve seen, the root cause is not the write speed of the SD card, but rather the use of sqlite as a database. Sqlite does a filesystem flush after every change to the database, which not only alters the blocks of the database on disk, but also the filesystem metadata of the sqlite database. This prevents the Linux kernel from grouping and optimizing disk writes, but on the other hand it makes sure the on-disk database will always be consistent and up-to-date.
Now the weak point of flash media is not in the write cycles, but in the erase cycles: flash blocks wear from erase cycles. Flash media controllers try to even out the wear by shuffling logical blocks around, but there’s only so little wear leveling an SD card can do. Given the amount of writes (and syncs) you get with a Hass system with many events, you can imagine the amount of wear the SD card gets is beyond the normal casual use the SD card vendors expect.
I have been thinking how to solve this for quite some time, and I’ve come up with some possible directions for solution. Here they are in random order:
- Create a tmpfs to put the sqlite database on it. Works great, but the database will not be persistent over crashes or reboots.
- As 1, and have a cron job copy the database back to disk every an hour. At boot, copy the database from disk to tmpfs, start hass, and off you go.
- Put the sqlite database on NFS storage backed by something that’s not flash, or by a lying NFS server telling the client “yes, I have synced your blocks to disk”, while at the same time finding a good time to actually group that bunch of writes to disk.
- Tell Hass to use an in-memory Sqlite database. Same as option 1, less fiddling, but not evern constistent over Hass restarts.
Configure like this:
recorder:
db_url: sqlite://
So far the easy options that don’t require any changes to hass.
A solution that needs coding is to tell Hass to put the sqlite database in memory (a RPi 3 has sufficient memory for that), and have Hass backup the database to disk once every hour (or on whatever configurable time interval). This is very easy to do in C, the Sqlite documentation even has example code. Unfortunately I haven’t found a way in SQLAlchemy to get to the underlying Sqlite connection, and even if I got, the pysqlite library doesn’t support the backup functions the C library does.
Regards,
Erik
Would switching the database to MySQL reduce the number of erase cycles?
A good way to go might be to just have the DB get written to disk when doing a reboot.
Though you’ll have to be careful because a HASS database get can get hundreds of MB in size pretty easily.
I don’t know if switching to MySQL or MariaDB reduces the number of erase cycles. I think it does because in my experience MySQL can be tuned to reduce the number of disk updates with the disadvantage of a corrupted database at a crash. Would be worth trying.
Another possibility would be to use a MySQL database on a remote host.
Regards,
Erik
After burning my first SD card within a few weeks of running hass I installed a 1,8" USB hdd to my rpi3. Now I use the sdcard only for the boot partition. USB boot did not work for me. Running everything from HDD feels faster than my SD card.
Today I would just by a cheap USB SSD.
1 Like
BBrendon
ok You gotta let me know how you’re doing that. I have a 4tb NAS with GigE and various SoCs including Odroid C2+, a couple PCDuino3 Nanos, An Odroid HC-1, and a couple PIs. I would love to just have them grab their image from the NAS. Right now I can’t even get hass to run from NAS.
Anyone had luck with mlc based nand cards? I’ve just ordered an industrial Kingston card in the hope it’s a bit more robust.
These are my very old notes. At least 3+ years old but I think my Pi is running the latest OS so it should sitll work. Good luck NFS mounting
Copy the root partition from the SD card to my NFS server: “tar -cf - --one-file-system -C / . | ssh server tar -xpf - -C /foo/rpi”
change /boot/cmdline.txt
From: dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
To: dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/nfs ip=dhcp nfsroot=192.168.1.11:/volume1/bb-rpi/root,vers=3 rw elevator=deadline rootwait
Comment out the eth0 lines in /etc/network/interfaces
comment out the root (/) mount in /etc/fstab
http://www.raspberrypi.org/forums/viewtopic.php?f=2&t=5974
http://blogs.wcode.org/2013/09/howto-netboot-a-raspberry-pi/
Anybody tried booting completely off USB? https://github.com/raspberrypi/documentation/blob/master/hardware/raspberrypi/bootmodes/msd.md
This is only possible with rpi3, but if that works I would consider upgrading my pies
My pi’s are fully running on a SSD connected to USB. No SD-card what so ever.
I’m running off a 32GB USB drive, on my RaspberryPI 3 with no SD card installed. I followed the instructions here:
https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md
1 Like
Raspberry Pi system is quite fragile… So, I, persnally, constantly needed a backup. But now, Ihave solved the issue)) This backup has really helped How to Backup up and Restore your Raspberry Pi SD Card
I run Hass on raspbian with
- Root filesystem RO
- home-dir in memory overlayfs
I used the following instructions
Is it stable? Running a pi 3B+ crashes within a week. On my fourth rebuild.
It was stable until the 32GB drive became corrupted (it was an old thumb drive I’ve had for several years) I replaced it with a new 128GB thumb drive in early October, and haven’t had any problems.
I run Hassbian, and back it up a couple of times a week.