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

[fabienp]

surtout que mettre le système sur usb (ssd ou autre) j'ai testé y a 2 ans, c'était pas pratique pour faire les backup, puis re installer en cas de soucis...
si la carte SD tiens plus de 2 ans, ça m'ira, tout les 2 ans je la changerai même si elle est pas dead, je m'en servirai ailleurs (reflex, smartphone, gopro, style cle usb, sur le Pi qui sert de mediacenter (kodi) ou autre).

[benbidouille]

J'approuve la solution avec HDD qui me parait une excellente solution pour délester la SD card.

En Disk Dur parfaitement adapté pour RPI avec toute la connectique adhoc pour peu que votre alim fasse 3A y a ceci de parfait, Livraison en 72h très fiable.

https://www.wdc.com/fr-fr/products/wdla ... WD2500LMCW

et si vous voulez avoir un ensemble sans cables USB dans tous les sens, voici un boitier qui intègre RPI et HDD

https://www.wdc.com/fr-fr/products/wdla ... quare.html

Le tout a des prix que je trouve très raisonnables, promos en cours.

[fabienp]

même si j'ai pas adopté la solution, quitte a déporté le système de la micro SD, autant le mettre sur un SSD, vue que domoticz est destiné a tourner 24/24, un SSD chauffe moins et consomme moins. Et les prix dans les petites capacité sont devenu très abordable.

[lost]

pour peu que votre alim fasse 3A y a ceci de parfait...

3A, c'est beaucoup quand on pense que mon PI (en install raspbian lite, cad sans interface graphique inutile vu que pas d'écran => le GPU ne consomme pas)... se contente de l'USB de la Livebox donné pour la moitié!

Ce qui minimise aussi les besoins si on veut une alim sauvegardée: Dans mon cas, la batterie tampon de 12V intercalée sur l'alim 12V LB assure aussi le 5V du PI en cas de panne de courant.

Et se retrouver avec un HDD 2.5" qui fait 3 fois la surface du PI... Non, franchement, faudrait que la fondation Raspberry arrête de juger notre usage comme marginal et propose une possibilité de stockage fiable. Et eUSB en serait une qui ne coûterait rien aux utilisateurs pas concernés, c'est juste un connecteur du type de ceux IO, moins grand, à avoir côté PCB. Et que le boot loader du PI boot sur USB sans bidouille, ce qui au passage éviterait aussi de devoir installer sur SD avec une image préconfigurée. Cela se ferait comme sur un PC en bootant sur une clef USB dans un des ports externes.

Il commence a y avoir des PC barebones Intel chinois pas plus cher qu'un PI avec toutes les verrues autour. A un moment s'ils n'évoluent pas le choix va être vite fait.

[manuloup]

Bien d'accord avec tout ceci. Le stockage reste le problème principal du PI. J'attends également des solutions genre batterie solaire pour les rendre indépendant d'une prise électrique. Wait and see.

[benbidouille]

3A, c'est beaucoup quand on pense que mon PI

J'étais sur en écrivant ces mots, que cela susciterait des réactions et suis bien conscient que 3A est surdimensionné.

Jusqu’avant l'installation du disk USB WDPidrive, donc RPI seul, j'ai toujours fonctionné en alimenté via un port USB tout comme toi et sans me préoccuper de la consommation effective, et d'ailleurs sans jamais avoir eu de problème particulier.

C'est à l'occasion de l'ajout du disk USB, mais aussi parce que j'avais besoin de libérer le port USB que je n'utilisais que pour alimenter le Pi, que j'ai ajouté une vraie Alim ( promo site WDlab).

Il me parait tout comme toi totalement démesuré d'imaginer que 3A soient nécessaires, mais je n'ai trouvé aucune spec technique du disk dur et consommation autres que "low consommation", j'imagine pour Pi + HDD un max absolu en pointe supérieur a ce qu'un port USB délivre en standard 500mA et peut être aller jusqu' 1A, bref l’alim 3A surdimensionnée c’est pour assurer le coup et fiabiliser l'ensemble.

Je ferai des mesures de courant et vous tiendrai au courant

le sujet m’intéresse d’autant plus qu'en conclusion des débats sur la longévités des cartes SD, j'en retiens que la sauvegarde de l'alimentation du Pi est essentiel et l'ajout d'un disk HDD à la carte SD ne solutionne que le phénomène d'usure de celle ci, qui semble il n'est pas le plus critique , même avec des taux de 3GB/jours.

Je souhaite donc éviter la solution "grosse bertha" et l’achat d'un UPS/onduleur qui nul doute est une bonne solution, aussi j'envisage la réalisation d'une batterie tampon avec le 5V d'alim du Pi + HDD avec détection de présence l'alim principale pour ordonner un shutdown propre du Pi et du HDD et un redémarrage automatique dans les règles de l'art.

En quelque sorte à l'image de ce que proposait @banditos, un UPS ou tampon dimensionné pour le PI + HDD seul, dès lors que le secteur est tombé pas sur qu'il soit nécessaire de conserver le Pi sous tension.

[rimram31]

...

Je te réponds ici et par curiosité j'ai regardé le contenu des fichiers ext4 décrits par lost plus haut:

Code : Tout sélectionner

$ cat /sys/fs/ext4/mmcblk0p2/session_write_kbytes
45248
$ cat /sys/fs/ext4/mmcblk0p3/session_write_kbytes
8591656
p$ uptime
 18:41:14 up 29 days, 11:16,  0 users,  load average: 0.12, 0.12, 0.13

J'avais créé deux partitions, une "système", / et sur la deuxième j'ai monté /home et donc finalement domoticz.

Depuis a peu près un mois de mon dernier redémarrage (domoticz qui plante parfois ...), 29 jours, deux éléments. J'obtiens a peu près le meme ratio que lost plus haut mais pour quasi 10 fois plus de temps de fonctionnement, donc 10 x moins de write ??? Et aussi la partie sollicitée et d'évidence la db domoticz, la partition / système (mais normalement en ro chez moi) est peu sollicitée.

Je m'étais posé ces questions de longévité il y a deux ans et j'avais décrit quelques manips ici viewtopic.php?f=9&t=1582&start=10 Deux ans a peu près donc puisque la carte que j'ai du changer c'était a peu près a cette époque Février/Mars en 2016 Ma 1ere carte n'avait pas tenu plus de 3 mois, la carte actuelle est une kingston 16G sur laquelle "seulement" 3G sont disponibles (2G système, 1G home), environ 50% d'utilisés.

Autre élément peut-être intéressant, je viens de mettre a jour un autre pi lui "de salon" qui tournait sur une raspbian depuis 5 ou 6 ans et sans aucun souci de carte (je l'ai changé pour un pi 3). L'écriture importante est donc a chercher je pense plus coté domoticz, probablement la db.

J'avais travaillé sur une version avec la db en mémoire mais je ne l'ai pas mise en place, surpris que toi bien que tu l'ai mise en mémoire tu ais autant d'écriture. Il est plus que probable que l'essentiel des write sont a chercher de ce coté, pkoi pas d'ailleurs voir si il y a pas moyen de réduire les écritures coté code dz. On a pas obligatoirement besoin des relevés de T toutes les x minutes en tout cas pas glop pour la carte sd que ces données soient stockées sur cette carte.

Pour finir, je n'ai toujours pas depuis mis a jour ma version de dz, ça peut être pertinent, je suis toujours en 2.3869 version d(il y a deux ans.

Vos posts me font penser qu'il faudra ce printemps que je fasse une maj de mes backup cards assez probable que ma carte ne tienne plus trop longtemps ...

[benbidouille]

Depuis a peu près un mois de mon dernier redémarrage (domoticz qui plante parfois ...), 29 jours, deux éléments. J'obtiens a peu près le meme ratio que lost plus haut mais pour quasi 10 fois plus de temps de fonctionnement, donc 10 x moins de write ???

Le fait que tu es un ratio de x10 avec @lost soit 291MB/jour me parait tout a fait cohérent avec le fait d'avoir mis les domoticz.db-wal et domoticz.db-shm en tmpfs, de mon coté avec une configuration comparable j'atteins les 314MB/jour ce qui me parait une attitude plutôt précautionneuse pour nos cartes SD.

J'avais promis de faire des mesures de consommation, les voici donc avec une consommation moyenne RFlink + Rpi3 + HDD PiDrive: 430mA soit 2,15W

Lors de la sollicitation du HDD, la consommation moyenne atteint 520mA et lors des phase de Shutdown et Start, un grand maximum de 670mA est atteint ponctuellement. Le RF Link contribue pour 50mA en moyenne.

Tout ceci me parait tout à fait compatible avec un UPS DIY pour sécuriser un shutdown propre lors de la perte du secteur et redémarrage propre au retour de celui-ci.

[lost]

Le fait que tu es un ratio de x10 avec @lost soit 291MB/jour me parait tout a fait cohérent avec le fait d'avoir mis les domoticz.db-wal et domoticz.db-shm en tmpfs, de mon coté avec une configuration comparable j'atteins les 314MB/jour ce qui me parait une attitude plutôt précautionneuse pour nos cartes SD.

Au delà du sysfs ext4 qui ne permet pas de grosse choses côté bufferisation avant écriture réelle:
https://www.kernel.org/doc/Documentatio ... fs-fs-ext4

Il y a celui de la virtual memory:
https://www.kernel.org/doc/Documentation/sysctl/vm.txt

Là, on peut modifier (et vérifier l'impact de) la façon de cacher les données avec des limites en ratio vs espace ram dispo et/ou en temps d'expiration (par défaut, un temps de writeback à 5s et de expire à 30s. Temps que l'on peut déjà majorer tout en regardant si les ratios ne sont pas atteints).

Si je voulais optimiser plus, je pense que je passerais par là plutôt que mettre carrément la db domoticz en tmpfs: On va limiter les écritures en les regroupant mieux et sur un crash contrôlé (côté système), on ne perds rien (tout sera flushé)... tandis que sur un crash incontrôlé on va perdre au max les écritures des temps ci dessus majorés.

Cela peut faire un bon compromis. Pas trop d'écritures/pas trop de perte potentielle. Et cela concernera l'usage de tout le stockage (y compris logs systèmes...).

Un bon article pratique sur ce sujet:
https://lonesysadmin.net/2013/12/22/bet ... rty_ratio/

[lost]

[
Un bon article pratique sur ce sujet:
https://lonesysadmin.net/2013/12/22/bet ... rty_ratio/

Pour info, changer ces valeurs vs defaut, soit dans le sysctl.conf soit pour tester dans les pseudo-fichiers:
vm.dirty_ratio = 60
vm.dirty_expire_centisecs = 120000

Améliore déjà grandement la réactivité de l'interface http de Domoticz. A voir l'impact écritures SD dans le temps (au moins, plus d'écritures intermédiaires devraient se faire dans les cache en ram sans rinçer la SD). Pour ma part, l'alim du PI étant sauvegardée cela ne devrait pas poser de pb.