Evolution de techniques pour préserver les cartes SD?

[k_sartor]

Bonjour,
j'utilise depuis des années log2ram pour les fichiers disponibles dans /var/log

Historiquement (https://www.magdiblog.fr/divers/comment ... pberry-pi/), je vois qu'il était conseillé de mettre en ram également les dossiers /tmp et /var/tmp

Est-ce toujours le cas?

Finalement, j'avais lu à l'époque que l'on pouvait identifier les fichiers qui ont été modifiés dans les x (ici 240) dernières minutes via la commande suivante:
sudo find / -not -path '/sys*' -not -path '/dev*' -not -path '/proc*' -mmin -240

J'ai supposé que les /sys, /dev et /proc ne sont pas problématiques pour les écriture, mais est-ce correct?

Je constate également qu'il y a plusieurs résultats dans /run/log/journal (systemd si j'ai bien compris - je suis sous rapsbian): est ce que le dossier /run écrit aussi des données sur la carte SD (car dans mon cas il y a plusieurs fichiers de 6 Mo qui y sont)
Idem, il y a plusieurs résultats dans /run/systemd/ et var/lib/systemd

Dois-je m'en inquiéter pour améliorer la durée de vie de ma carte SD?

Pour info, une carte SD Sandisk vient de me quitter après un peu moins de 3 ans et j'aimerais étendre cette durée de vie, merci

[piper]

Bonjour,
Il y a des choses essentiels au systeme (/sys, /dev, /proc)
Qui sont des dossiers dans lesquels, il est rarissime que quelque chose soit écrit
(Ex : nouvel écriture dans /dev si un nouveau périphérique est détecté)

Pour maintenir une carte SD en bonne santé il faut :
- ne pas mettre de base de données dessus (pas de MySQL !!! ou autre SGBD de ce genre)
- si possible (si la quantité de RAM est suffisante) : désactiver le swap sur disque, voir si le swap en mémoire compressée (zram) est utilisable en cas de besoin impérieux de mémoire swap
- limiter les écritures de logs des services

Pour ce derniers points, plusieurs options
- Dans nos programmes qu'on développe nous même : n'écrire que ce qui est indispensable
- On peut désactiver le logging service par service , plusieurs solutions (Ex : pour Apache on peut mettre accesslog et errorlog à /dev/null ou dans un fichier descripteur d'un service particulier pour systemd mettre StandardOutput=null et StandardError=null)
- On peut aussi stopper systemd-journald.service et rsyslog en utilisant la fonction systemctl mask "nomduservice"
- On peut aussi aller dans /etc/rsyslog.conf pour ne désactiver que certains logs système

Les possibilités sont grandes pour disposer d'un Linux qui logue uniquement ce qui serait utile à un debogage.
Car il n'y a rien de pire que de se retrouver avec un mauvais fonctionnement sans avoir d'information de l'erreur juste par ce qu'on a désactivé les logs dont on aurait besoin.

Ex : si j'ai un apache qui tourne sur un raspberry, je désactive les logs d'accès mais pas celles des erreurs.
Si mon Pi est accessible en ssh par internet, je garde les logs de sshd
Idem pour un service ftp : je désactive les logs de transfert, je garde celles d'identification.

Enfin, si un Pi doit héberger une base de données et qu'on n'a pas le choix alors oublier la carte SD et mettre un disque dur.

[destroyedlolo]

Salut,

Il y a des choses essentiels au systeme (/sys, /dev, /proc)
Qui sont des dossiers dans lesquels, il est rarissime que quelque chose soit écrit
(Ex : nouvel écriture dans /dev si un nouveau périphérique est détecté)

C'est surtout que se sont des FS "virtuels" qui ne sont que des vues de ce qu'il se passe dans le kernel.
Du coup, hormis leur point d'entrée, ils n'existent pas physiquement sur les disques (ou alors, c'est que RapberryOS est encore plus mal configuré que je ne le pensais).

Mais il y en a d'autres comme /run qui n'ont aucune raison d'être sur disque.

sur la tablette qui me servait de tableau de bord pour ma domotique et qui n'avait que sa SD, j'avais aussi mis /var/log et /home/<mon_utilisateur> en RAM. Évidemment, on perd tout à chaque reboot (mais dans ce cas, ca n'avait pas d'importance), mais on est sur que les logs et les traces de login (historique par exemple) ne font AUCUNE écriture.

[k_sartor]

Bonjour,
merci pour vos réponses.
En l'occurence, j'avais déjà mis tout var/log dans en ram via log2ram.
J'ai découvert que mon logiciel de domotique (avec plusieurs 10aines de capteurs) écrivait environ 100 Mo par heure... via sa base de données.
Je l'ai (=la base de donnnées) mise en RAM dans log2ram et au pire en cas de crash, je perds 24 h de données ce qui n'est pas critique pour mes applications.
Tous mes programmes qui doivent écrire quelque chose le font en RAM (via log2ram).
Historiquement j'avais mis /tmp en ram mais je l'ai enlevé car je me suis rendu compte que pour l'installation de certains programmes la taille de la partition "virtuelle" de 50 Mo était trop juste et faisait planter la mise à jour

[dyox]

Bonjour,

J'utilise un équivalent de log2ram, zram-config.

Je l'ai (=la base de donnnées) mise en RAM dans log2ram et au pire en cas de crash, je perds 24 h de données ce qui n'est pas critique pour mes applications.

On peut diminuer le timer de 24h de log2ram et mettre 6h si on préfère.

Historiquement j'avais mis /tmp en ram mais je l'ai enlevé car je me suis rendu compte que pour l'installation de certains programmes la taille de la partition "virtuelle" de 50 Mo était trop juste et faisait planter la mise à jour

On peut aussi augmenter la taille du /tmp.

Il est vrai que la pi est une tueuse de carte sd...car tout le monde achète les cartes les moins chères et standards alors qu'il faudrait acheter des cartes professionnelles qui sont beaucoup plus endurantes.
Il existe les clés usb qui sont plus endurantes que les cartes.

Si le système peut être "figé" et qu'il fonctionne bien, on peut passer "/" (rootfs) en lecteur seule (ro). Par contre, je ne sais plus si on peut le faire dans le cmdline, sinon cela se passe dans le fstab.

Il reste aussi le choix de la distribution, DietPi peut s'avérer utile.

[destroyedlolo]

Salut,

Historiquement j'avais mis /tmp en ram mais je l'ai enlevé car je me suis rendu compte que pour l'installation de certains programmes la taille de la partition "virtuelle" de 50 Mo était trop juste et faisait planter la mise à jour

C'est une TRES TRES mauvaise idée. Autant pour /var/tmp, ca se discute suivant les utilisations, autant /tmp, simplement NON : le système et les applies y écrivent tout et n'importe quoi, tout le temps.
De plus, normalement, ton /tmp ne devrait pas être limité a 50Mo : si aucune taille ne lui est fourni, il devrait prendre au plus (dynamique) la moitié de la RAM physique dispo. Les RAM disk de taille fixe n'ont plus la moindre utilité de nos jours (et même avant d'ailleurs )

Il est vrai que la pi est une tueuse de carte sd...

C'est juste une légende urbaine qui a la vie dure
Non, les PI ne tuent pas les cartes :

• c'est soit leur OS qui est pourri et mal configuré (ce qui fut longtemps le cas de Raspbian, peut être encore le cas, je n'utilise pas)
• soit c'est l'utilisateur qui y met des trucs qui ne sont pas adapté pour. Typiquement une BDD sans configurer le cache adéquate.

Mon PI de dev tourne H24 depuis au moins 7 ans avec l'OS entièrement sur la SD que je n'ai jamais grillée. Mais il n'y a strictement aucune écriture sur cette dernière hormis mise à jour de l'OS.

A+

[piper]

Mon PI de dev tourne H24 depuis au moins 7 ans avec l'OS entièrement sur la SD que je n'ai jamais grillée. Mais il n'y a strictement aucune écriture sur cette dernière hormis mise à jour de l'OS.

Oui, moi aussi j'ai des Pi qui tournent tous les jours depuis 2010 avec toujours la même carte SD.
Pas de bureau, un OS minimaliste, un service qui reçoit des infos de sondes et déclenche des évènements sur des sorties. Pas de swap (vu le peu de RAM que consomme l'ensemble c'est inutile).
Pas d'écran, pas de souris, pas de clavier : juste un accès ssh
Pour paramétrer cet "IOT" par un "utilisateur final" : 2 pages web, les paramètres sont stockées dans une bdd sqlite qui a 2 tables, 10 lignes max et dans laquelle, on n'écrit que pour ajouter un utilisateur, c'est à dire : 1 fois tous les 5 ans.
Le service web ne logue rien : ni erreur, ni accès. même rsyslog est désactivé
Et ce bazard fonctionne dans des conditions de températures (entre 0 et 50°C), de pression variable (entre 1040 et 600 hPa) et des conditions vibratoires assez extrêmes et par dessus le marché sont éteint à la mode brutale (coupure d'alimentation)

[k_sartor]

Dans mon cas, j'ai drastiquement réduit l'usage des accès disque en mettant le logiciel domotique (et sa BDD associée) dans un ram disk via log2ram (de 100 Mo)
Avant j'avais environ 3 Go apparemment écrit par jour, là je suis à 100 Mo (et à mon avis du à des BU journalier qui transitent par la SD avant l'envoi sur un FTP externe)

=> Pour le /tmp en ram disk, je pense que j'avais lu cela sur le site de la framboise (viewtopic.php?t=1196) mais pas que.

Merci pour l'info de l'allocation automatique du ram-disk, je n'avais jamais trouvé cette information. Je vais voir si log2ram sait je gérer ou non...

[destroyedlolo]

Apres avoir parcouru le lien que tu donnes, je tiens à préciser que je parlais de tmpfs : je ne sais pas si ca s'applique aussi a ramfs qui n'est plus utilisé depuis des lustres.
Pour mes logs, j'utilise zram qui a l'avantage en plus de compresser le contenu, très utile pour les logs.