reza wrote: ↑Tuesday 11 June 2024 0:30
Can you find one of the best solutions (...) without the need for a network and only through the settings or programs of the Raspberry Pi itself and put it on the wiki?
IMO, that's not really a Domoticz wiki subject: That's pure Linux setup with many tips available on the net with the right keywords.
+ at the very beginning, SD card choice is probably the most important.
reza wrote: ↑Wednesday 05 June 2024 10:29
What is the approximate lifespan of a 300 GB SSD hard drive for domoticz?
1st: Why needing so much space? My current setup is using a 64GB Sandisk Extreme Pro in A2 standard. And if I decided to buy a 64GB card, that's just because 32GB ones are limited to A1(probably because SD storage controller is not using a dual-channel mode to simultaneously address 2 flash chips, kind of internal RAID 0, on 32GB exact same device versions): Partition table is limited to 32 GB, so halved capacity (with management benefit as no TRIM for SD cards + less size for physical dumps savings I do once after a new raspbian update or python plugins dependencies additions ; intermediate savings are only an archive of domoticz folder).
2nd: It depends! Usually good SSD's shows their TBW (Tera-Byte-Written) specification. Monitoring your average daily write use (Ext4 FS store disk usage since format being done and also since last mount) so after a few days/weeks of uptime, that's just a division.
For instance, on my system I have these partitions (that's SD, so a /dev/mmc on a Raspberry):
Code: Select all
$ mount | grep '^/dev/'
/dev/mmcblk0p2 on / type ext4 (rw,noatime,commit=20)
/dev/mmcblk0p3 on /local type ext4 (rw,relatime,commit=20)
/dev/mmcblk0p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
boot is no interest and local is only used for some local savings on another partition (doesn't saves you from a device failure, but at least from file-system issues) so for the root (/) one for mmcblk0p2 we have:
Code: Select all
$ cat /sys/fs/ext4/mmcblk0p2/session_write_kbytes
35921412
$ cat /sys/fs/ext4/mmcblk0p2/lifetime_write_kbytes
625743393
and I did restard my system recently:
Code: Select all
$ uptime
14:36:53 up 13 days, 20:12, 1 user, load average: 0.06, 0.08, 0.08
So, that's almost 14 days and 35921412kB = 34GB written meantime. So ~2.4GB/day recently.
Since FS creation when this PI was reinstalled (in january 23, so ~17 month) that's 625743393kB = 597GB. So 1.2GB/day on a long average.
With storage TBW data, when available from manufacturer, these Ext4 and uptime info calculus allows you to forecast your own use-case endurance.
Another option to evaluate SSD reliability is to divide TBW (*1024 to have this data in GB) with capacity (in GB): The higher figure the better, as this is linked (up to so called "write-amplification" linked to device flash management) quite directly with the underlying flash chips endurance (allowed number of sector erase cycles: FYI, this was 100k figures in the SLC times and dropped to a few 10k for MLC and a few 1k for TLC/QLC).
Anyway, adding /local (much less used) partition lifetime_write_kbytes:
Code: Select all
cat /sys/fs/ext4/mmcblk0p3/lifetime_write_kbytes
5678029
That's 5.4GB added to previous 597GB. so over 600GB for a 64GB device. So, for now, I wrote less than 10 times device capacity. That's still far from usual TBW/Capacity usual figures, even using crappy QLC flash devices: All are over a few hundred.
That's not 100% reliable science (this SD card already once needed a FSCK after a PI hang and showed IO error in dmesg, on boot partition which was quite surprising as only used during PI boot ; this was the reason for last restart & no more issue for now) and a specific device may show early failure. But you now have everything to do your own maths & forecasts, without forgetting savings!