ben53252642 wrote: ↑Tuesday 24 September 2019 23:40
Also if your starting with a Raspberry Pi, be sure to use an SSD not a Micro SD card. If you search around the forum, it's pretty well known that the Micro SD cards wear out rather quickly. Even better, build your new system on a cheap core i3 Intel NUC.
A PI for this kind of use is already overkill: Mine always never exceed 3% CPU load, can reach 10% when unattended upgrade triggers. So a NUC will just increase the electricity bill in 24/7 usage.
As well, uSD card will work for years with a few targeted changes.
On my side, I've setup a service that use a FTP to get IP cams around the house snapshots every 10s & cypher/compress/send them immediately on a gmail account. This is a lot of data that don't remain for long: All this is done using "ramdisks" with tmpfs mount points.
All domoticz stuff (DB etc) as well as raspbian logs (want to be still able to debug post mortem) remains on the SD, thanks to a few tuning in sysfs to allow more write buffering/merging than default configuration.
You can dig into this:
https://www.kernel.org/doc/Documentatio ... fs-fs-ext4
https://www.kernel.org/doc/Documentation/sysctl/vm.txt
This one is quite old but still valid (explanations, not values in our context):
https://lonesysadmin.net/2013/12/22/bet ... rty_ratio/
On my side I have this:
vm.dirty_ratio = 60
vm.dirty_expire_centisecs = 120000
Can set quite high figures because I run a minimal system (no desktop/graphical interface, almost useless on a headless system accessed only using ssh), that only use a small fraction of 1GB memory (+ GPU dedicated memory can be reduced to the min using raspi-config).
Thus that ability to buffer/merge writes up to 2mn (commit time=120s, if 60% available memory ratio not hit) instead of 5s, which makes a big difference on log files always opened in append mode.
This also improve Domoticz web page reactivity.
So, my advice is to understand, then test & try available ext4 (not so much) and vmm (the gold mine!) sysfs tunables before spending money for an external SSD bigger than the PI case.
On uSD side, device choice also makes a difference: You have now the A1/A2 standards (for applicative loads, with better IO/s for A2) that are designed to extend smartphone internal memory. The big difference for us is theses ones are designed for an always on use case (very different from removable media use-case that is almost always off, thus not able to do background tasks): So you get static wear levelling (able to evenly distribute wear on the whole device efficiently) instead of dynamic (wear only distributed on underlying flash sectors that are written, thus a very small subset that quickly create hot-spots and early failures of whole devices for only a few sectors ruined).
To sum-up:
No need for a SSD is using an A1/A2 uSD from a good manufacturer + tuning a few vmm sysfs that'll allow much more write buffering/merge.