Limitation écriture périphériques flash/ssd

giovanna89 · Le 07/04/2023, à 14:57

Bonjour à tous,

Je me pose une question concernant certaines méthodes utilisées pour limiter les écritures effectuées par les OS installés sur des périphériques à mémoire flash (clé usb, carte SD, SSD).
J'ai mis SSD dans la liste, mais aujourd'hui, ces derniers peuvent largement encaisser de très nombreuses lectures/écritures. Ils sont là pour la forme et aussi par parce de nombreux tuto (plus ou moins récents) les mentionnent pour "optimiser" leur durée de vie.

J'ai pas mal fait de lectures le net, dont voici une liste non-exhaustive :
_ logiciel log2ram
_ rallonger l'intervale d'écriture des données sur le disque (option "commit" dans le fstab)
_ tmpfs en ram
_ cache firefox en ram

J'arrive à comprendre qu'avoir un tmpfs ou un cache en ram permet de réduire les écritures sur le disque.
En revanche, je ne comprends pas bien en quoi rallonger l'intervalle d'écriture (option commit dans le fstab) ou le logiciel log2ram permettent de limiter le nombre d'écriture.
En effet, quoiqu'il en soit les données (log, ...) qui seront regroupées en ram seront à un moment écrites sur le disque. La seule différence que je vois d'un oeil non expert, c'est qu'au lieu d'aller écrire constamment une petite quantité de données à intervalle réduit, on va regrouper en ram et écrire sur le périphérique une plus grosse quantité de donnée avec un intervalle plus grand. Mais cela ne change en rien (ou pas beaucoup) la quantité de données écrite sur ne périphérique.

Question annexe : sur ext4, l'intervalle d'écriture est défini par défaut à 5s. Sur btrfs, il est défini par défaut à 30s. Y-a-t-il une raison à ce qu'il y ait une telle différence ?

Cordialement

geole · Le 07/04/2023, à 21:11

Plonge.. tu verras la température.
Le plus important me semble d'éviter d'écrire deux fois la même chose.

Je crois ZFS n'écrit jamais sur les disques, sauf lorsqu'il n'y plus de place en RAM et qu'il faut bien se décider à virer quelque chose.

giovanna89 · Le 08/04/2023, à 10:46

bonjour,

Plonge.. tu verras la température.

Désolé, je n'ai pas compris la référence. Si tu voulais dire de voir par moi même, je ne suis pas assez calé et je ne sais pas comment faire.

Le plus important me semble d'éviter d'écrire deux fois la même chose.

c'est-à-dire ?

Je crois ZFS n'écrit jamais sur les disques, sauf lorsqu'il n'y plus de place en RAM et qu'il faut bien se décider à virer quelque chose.

C'est pareil, je ne m'y connais pas assez, mais le cache zfs, je crois que ce sont des données utilisateurs.
Pour avoir un nas fonctionnant sur truenas, lorsque j'ai migré de freenas 9 à truenas 13, les recommandations matériels avaient évoluées.
Il y a 6-7 ans sur freenas, on pouvait installer l'OS sur une clé usb. Dorénavant, l'éditeur recommande d'installer truenas sur un SSD. Je pense qu'il y a davantage de lecture / écriture qu'à l'époque.

iznobe · Le 08/04/2023, à 12:01

Il y a 6-7 ans sur freenas, on pouvait installer l'OS sur une clé usb. Dorénavant, l'éditeur recommande d'installer truenas sur un SSD.

Bonjour , une cle USB a une durée de vie tres limitée comparer a un SSD , c' est peut etre plutot ca qui fait pencher la balance non ? a la louche je dirais qu ' un SSD encaisse maintenant au moins 10000 fois plus de cycle d' ecriture qu ' une clé USB ... sans compter que c' est par cellule donc dependant de l ' espace occupé / vide donc au final la durée de vie d' un SSD est du genre 100 000 a 1 000 000 de fois plus longue qu ' une clé USB .

Pour zfs , je ne sais pas .

Ce qui est sur , c ' est qu ' il faut se renseigner correctement sur des sites de confiance sur le net , plutot que de faire des deductions plus ou moins bonnes .

mais au final , quel est l' objectif de ta discussion ?

Dernière modification par iznobe (Le 08/04/2023, à 12:02)

geole · Le 08/04/2023, à 12:02

Bonjour
1) Fais ton installation sans te compliquer la vie et raconte ce qui ne va pas.
2) Ce document ne devrait avoir que le paragraphe 4.6
3) Il y a six ans les SSD étaient encore très cher et le logiciel au moins deux fois plus petit.

giovanna89 · Le 08/04/2023, à 14:20

Re-
L'objectif de mon post est juste une réflexion de ma part, poussée par le fait de comprendre.
Il s'agit juste d'avoir un retour de personne qui s'y connaissent.

Pour résumé mon premier post :
_ je comprends qu'avoir un tmpfs en ram réduit les écritures sur le périphérique puisque tout se passe en ram.
_ mon incompréhension porte sur les solutions telle que log2ram ou la modification de l'option "commit" dans le fstab
Exemple d'une nouvelle installation, tout paramétrage est par défaut.
Il va y avoir par exemple 100 octets de log écrit toutes 10s.
Maintenant installons le logiciel log2ram. Celui-ci est défini pour écrire les données (log) aggrégées en ram une fois toutes les heures. Il va donc y avoir 36ko d'écriture toutes heures.
Finalement il y aura autant d'écriture sur le périphérique (clé usb/ carte flash /ssd) que si je n'avais pas log2ram.
Vous voyez où je veux en venir?

ps : pour les l'OS sur clé usb ou carte sd, je pensais plutôt aux cas des raspberryPi.

iznobe · Le 08/04/2023, à 17:52

log2ram comporte d' autres reglages que ce que tu decris .
Notamment l ' ecriture seulement a la fin de la session ou redemarrage de l' ordi par exemple . tu peux aussi le regler toutes les 4 ou 8 heures ...

Tu ne t ' arretes que sur un seul point l ' ecriture sur disque . Mais ce n' est pas le seul point a considerer . Apres tout depend du systeme , du support de stockage utilisé et de la personne qui gere le systeme .
Par exemple , si tu met les logs en RAM ( ce que je fais ) , mais qu ' il ne faut pas faire , pourquoi ? parce que lorsqu ' on met les logs en RAM , ca n' ecrit plus du tout sur le disque , tu me diras , c' est peut etre un bon point .
Sauf que non , pas pour tout le monde du moins , car si une personne cherche a consulter son journal apres un crash , il n ' y aura quedalle et elle pourrait ne pas comprendre pourquoi si c' est un reglage par defaut .
Dans mon cas , si je subis un crash ou 2 du meme type , vu que c' est moi qui ai placé ce " parametre " , je saurais ou aller chercher et remettre en place de façon a pouvoir investiguer derriere .

En gros , il y a les parametres par defaut , pour tout un chacun en tant qu ' utilisateur " standard " , et , sachant que l' on peut tout personnalisé comme on le souhaite , les personnalisations apportées par l' administrateur du systeme , qui lui , est censé savoir ce qu ' il fait et se dépatouiller ensuite en cas de soucis .

Pour les pi(s) , si tu regardes plus en profondeur sur leur forum , tu pourras meme monter le systeme de fichier racine , en RO seulement , aucune ecriture possible donc .
Ensuite , de temps en temps tu repasses en mode normal , tu fais les MAJ , les bidouillages , et tu redemarres en RO a nouveau .
Mais , comme expliqué dans l' exemple precedent , cela comporte des desavantages evidents , aucun log , pas de swap , pas de /temp , pas de cache etc ...

Tout est affaire de compromis plus ou moins grands .et aussi de savoir ce que l' on fait et comment revenir a une etat " par defaut " si besoin .

Dernière modification par iznobe (Le 08/04/2023, à 17:57)

giovanna89 · Le 10/04/2023, à 14:16

Arff, désolé, je pense que j'ai dû mal formulé mon post.

log2ram comporte d' autres reglages que ce que tu decris .
Notamment l ' ecriture seulement a la fin de la session ou redemarrage de l' ordi par exemple . tu peux aussi le regler toutes les 4 ou 8 heures ...
Tu ne t ' arretes que sur un seul point l ' ecriture sur disque . Mais ce n' est pas le seul point a considerer . Apres tout depend du systeme , du support de stockage utilisé et de la personne qui gere le systeme .
Par exemple , si tu met les logs en RAM ( ce que je fais ) , mais qu ' il ne faut pas faire , pourquoi ? parce que lorsqu ' on met les logs en RAM , ca n' ecrit plus du tout sur le disque , tu me diras , c' est peut etre un bon point .
Sauf que non , pas pour tout le monde du moins , car si une personne cherche a consulter son journal apres un crash , il n ' y aura quedalle et elle pourrait ne pas comprendre pourquoi si c' est un reglage par defaut .
Dans mon cas , si je subis un crash ou 2 du meme type , vu que c' est moi qui ai placé ce " parametre " , je saurais ou aller chercher et remettre en place de façon a pouvoir investiguer derriere .
En gros , il y a les paramètres par defaut , pour tout un chacun en tant qu ' utilisateur " standard " , et , sachant que l' on peut tout personnalisé comme on le souhaite , les personnalisations apportées par l' administrateur du systeme , qui lui , est censé savoir ce qu ' il fait et se dépatouiller ensuite en cas de soucis .

Oui tout a fait d'accord avec toi, effectivement si tu n'écris pas du tout les logs, et que s'il il t'arrive un truc tu te démerde pour désactiver log2ram pour résoudre ton problème. Oui, on va économiser les écritures.
Pour des utilisateurs lambda, qui vont installer log2ram dans sa version par défaut (ou avec quelques ajustements), mon questionnement est tout à fait légitime. La personne qui va allumer son ordi le matin et va l'éteindre le soir. Log2ram va inscrire par exemple 36Mo de log sur le périphérique à l'extinction plutôt que 3600 fois 10ko tout au long de la journée.

Pareil dans certains tuto de personnes qui ont l'air de s'y connaitre (en tout cas largement plus que moi), ils conseillent de passer le commit=5 à commit=60 de la partition racine dans le fstab. Je m'interroge de la pertinence (faisons abstraction des cas des ssd) d'une telle manipulation. Au bout d'une heure j'aurais écrit sur le périphérique autant de données que je le fasse toutes les 5s ou toutes les 60s.
A la limite, il y aura peut-être une optimisation au niveau de réactivité du système, mais je ne vois pas "l'économie d'écriture".

Je me doute que ces options/logiciels doivent être utiles dans certaines situations spécifiques (comme tu l'a évoqué, dans ton cas, tu n'écris pas du tout les logs et le jour où il arrive un truc, ba il faut que tu désactives le logiciel et que tu reproduises l'erreur pour pouvoir la solutionner).
Mais pour celui qui veut optimiser son système et qui suit ce genre de tuto, je ne suis pas sur du gain de ces manipulations dans le cadre de ce qu'on lui a "vendu" (limiter le nombre d'écritures disques).

Mais peut-être qu'il y a une vrai économie d'écriture, mais je ne suis pas suffisamment initié pour comprendre tout seul. Le sujet reste ouvert, c'est vraiment une question de fond.

iznobe · Le 10/04/2023, à 15:41

Salut .

Pour des utilisateurs lambda, qui vont installer log2ram dans sa version par défaut (ou avec quelques ajustements), mon questionnement est tout à fait légitime. La personne qui va allumer son ordi le matin et va l'éteindre le soir. Log2ram va inscrire par exemple 36Mo de log sur le périphérique à l'extinction plutôt que 3600 fois 10ko tout au long de la journée.

En fait non . imaginons qu ' une variable est modifiée 10 fois ( ou plus ) sur une periode d ' une heure , alors en RAM , cette variable sera modifié 10 fois ( ou + ) , par contre sur le disque , elle ne sera ecrite que 2 fois , une fois a l' initialisation , et une fois dans son dernier etat connu au moment ou log2ram va ecrire apres une heure sur le disque .

Donc le volume total de données ecrites / modifiées , n' est pas identique en RAM , et apres une heure , au moment de l' ecriture sur disque .

Dernière modification par iznobe (Le 10/04/2023, à 15:42)

giovanna89 · Le 11/04/2023, à 08:11

Top, c'est c'est exactement ce que je souhaitais savoir.
Même si je ne comprends pas les mécanismes sous-jacents, ces outils ont donc un réel intérêts pour une utilisation générale.

Merci

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 07/04/2023, à 14:57

Limitation écriture périphériques flash/ssd

#2 Le 07/04/2023, à 21:11

Re : Limitation écriture périphériques flash/ssd

#3 Le 08/04/2023, à 10:46

Re : Limitation écriture périphériques flash/ssd

#4 Le 08/04/2023, à 12:01

Re : Limitation écriture périphériques flash/ssd

#5 Le 08/04/2023, à 12:02

Re : Limitation écriture périphériques flash/ssd

#6 Le 08/04/2023, à 14:20

Re : Limitation écriture périphériques flash/ssd

#7 Le 08/04/2023, à 17:52

Re : Limitation écriture périphériques flash/ssd

#8 Le 10/04/2023, à 14:16

Re : Limitation écriture périphériques flash/ssd

#9 Le 10/04/2023, à 15:41

Re : Limitation écriture périphériques flash/ssd

#10 Le 11/04/2023, à 08:11

Re : Limitation écriture périphériques flash/ssd

Pied de page des forums