problem with crash SD card

[reza]

You can also boot the raspberry pi from network or use "iscsi boot", or you mount a NFS volume and run domoticz from this folder... there are endless options

Can you find one of the best solutions (such as the contract of all items in a RAM drive) without the need for a network and only through the settings or programs of the Raspberry Pi itself and put it on the wiki?
thank you

[lost]

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.

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!