Longevité carte SD - Taux d'ecriture et config sur RPi

[Doume]

Lorsque l'on crée un filesystem 'tmpfs' en RAM pour y mettre les logs, l'espace est affecté une fois pour toute, et n'évolue pas ensuite : C'est comme une clé USB : sa taille ne change pas avec le temps, au fur et à mesure que l'on écrit dessus.
Lorsque le filesystem est plein, il y a un message d'erreur et/ou un crash, c'est tout !

[fabienp]

a mince, je pensais pas, ça doit venir d'ailleurs alors.
me faudra redémarrer pour tester, et je vai peut m'y résigné car je veux faire des essais sous alexa...

[domcars0]

Lorsque l'on crée un filesystem 'tmpfs' en RAM pour y mettre les logs, l'espace est affecté une fois pour toute, et n'évolue pas ensuite : C'est comme une clé USB : sa taille ne change pas avec le temps, au fur et à mesure que l'on écrit dessus.
Lorsque le filesystem est plein, il y a un message d'erreur et/ou un crash, c'est tout !

Je ne suis pas du tout sûr de cela ( ce serait inefficace)....La taille configurée pour un tmpfs est la taille maximale de RAM qui sera effectivement allouée à cet espace....Si on utilise moins, le noyau ne 'réserve' pas cette RAM qui est plus utile pour une appli ( lui permettant d'eviter de swapper) ou même pour du cache ( permettant à une appli de redémarrer plus rapidement,). Par contre le tmpfs sera prioritaire tant qu'il n'aura pas atteint la taille configurée.

Exemple :

pi@meteo:~ $ df -h
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
/dev/root 15G 1,2G 13G 9% /
devtmpfs 213M 0 213M 0% /dev
tmpfs 217M 0 217M 0% /dev/shm
tmpfs 217M 23M 195M 11% /run
tmpfs 5,0M 0 5,0M 0% /run/lock
tmpfs 217M 0 217M 0% /sys/fs/cgroup
tmpfs 70M 43M 28M 61% /var/www/weewx
tmpfs 217M 0 217M 0% /tmp
/dev/mmcblk0p1 43M 22M 21M 51% /boot
log2ram 40M 1,8M 39M 5% /var/log
tmpfs 44M 0 44M 0% /run/user/1000

Sur ce Pi Zéro ( 500Mo de RAM), on a bien plus de 500Mo de file système au format tmpfs !!! Comment est-ce possible?
Et pourtant :
pi@meteo:~ $ free
total used free shared buff/cache available
Mem: 443900 65844 66112 67816 311944 256240
Swap: 102396 768 101628

il reste prêt 66Mo de RAM libre ...
En fait, avec la commande free, on va constater que la mémoire 'totale' va varier dans le temps. C'est qu'en fait cette mémoire totale est la mémoire totale physique (réelle), diminuée de l'espace tmpfs effectivement occupé (pas celle qui est configurée).
La RAM disponible va donc diminuer au fur et à mesure que les filesystems tmpfs vont se remplir, dans la limite de leur taille respective configurée.

[lost]

Je deterre un peu ce topic pour dire que même sans tout mettre en tmpfs, ma uSD industrielle de 32GB tiens ses 1.5GB d'écriture journaliers depuis 19 mois sans rien qui annonce une défaillance (comme des écritures devenant très lentes).

Sans tomber dans ce type de carte, il est possible qu'utiliser des cartes optimisées pour un usage constant et non épisodique (ce qui est plus courant dans un smartphone qu'un appareil photo/caméra) permette de bénéficier des mêmes avantages (gestion du wear levelling plus proche d'un SSD interne).

En particulier, les cartes Ax (A comme "applicatif", A2 permettant plus d'IO/s que A1) certification s'ajoutant aux classes de débit pré-existantes, sont sans doute à privilégier: Celles là sont a priori faites pour un usage constant, avec le temps et la possibilité de gérer les opérations d'arrière plan requises par un wear leveling statique.

[Antori91]

Bonjour,

De mon côté, je suis le fichier error_count (/sys/fs/ext4/mmcblkOp7/errors_count) en prévision de problèmes potentiels, sans être certain que cette information soit fiable.

Sur le Raspberry où j'ai installé Domoticz, j'utilise un disque dur connecté en USB et ai placé le log et la base de données de Domoticz sur ce disque dur. Raspbian ainsi que Domoticz hors base de données sont eux restés sur la SDcard. Je lance Domoticz avec les paramètres -log et -dbase. En dehors du fait qu'il faut modifier le fichier /etc/init.d/domoticz.sh, je trouve que c'est assez simple à mettre en oeuvre et cela fonctionne correctement. A noter aussi que ce fichier /etc/init.d/domoticz.sh n'est pas modifié lors des mises à jour (appréciable!). Exemple de modification pour un HD monté à /home/pi/Samba:

# edit to move Log and Db files to HARD DISK drive
DAEMON_ARGS="$DAEMON_ARGS -log /home/pi/Samba/domoticz/domoticz.txt"
DAEMON_ARGS="$DAEMON_ARGS -dbase /home/pi/Samba/domoticz/domoticz.db"
# end of edit

# edit to move BackUp files and SQLite Temp files to HARD DISK drive
ln -sf /home/pi/Samba/domoticz/domoticz.db-shm /home/pi/domoticz
ln -sf /home/pi/Samba/domoticz/domoticz.db-wal /home/pi/domoticz
ln -sf /home/pi/Samba/domoticz/backups /home/pi/domoticz
# end of edit

[fabienp]

De mon coté ma micro SD sandisk acheter sur amazon tiens toujours de aout 2016 sans aucun soucis et ça tourne H24.
Et ça écris toujours autant!

[mike913]

Bonjour,
idem pour moi ma carte sd tiens depuis plusieurs années sans problème.

[Thorgal]

Par curiosité, il y en a ici qui utilise log2ram pour la database ?

[Keros]

Pour la base de donnée ??

[Thorgal]

Yep, les liens symboliques ne marchent plus, mais il y a toujours moyen d'utilser le ramdisk comme chemin pour les 2 fichiers de la database, et d'utiliser log2ram pour gerer le tout.

En theorie, il suffit d'installer log2ram, et de mettre le chemin de ce "fichier tampon" comme chemin pour les 2 fichiers domoticz.

Mais le retours sont peux nombreux ....