SSD et obsolescence programmée ?

Caille · Le 19/02/2021, à 18:59

Bonjour,

Je me pose toujours des questions au sujet des SSD.
Suivant le type de puces mémoires le nombre de TBW varie, sans être éternel, ne pourrait-on pas parler d'obsolescence programmée ?
Pour quelles raisons les puces s'usent-elles, serait-il possible de créer des SSD avec des puces "éternelles", comme de la RAM par exemple ?
Attention je ne fais pas une fixette sur cette histoire de TBW, mais j'aimerai comprendre les raisons réelles de cette usure.
J'ai déjà constaté à plusieurs reprises des problèmes de plantages sur des cartes mémoires microSD, échangées à chaque fois (3 fois) par Sandisk, c'est probablement également lié au TBW ?

Cordialement.

Zakhar · Le 19/02/2021, à 19:55

En pratique, les SSD (de marque correcte) durent "suffisamment". Rien n'est éternel de toute façon, surtout en informatique où les normes évoluent, et au bout de 10 ans l'espace disque et les vitesses ont tellement changé que tu peux songer à remplacer.

Exemple sur mon SSD sur ce PC:

$ sudo ~/Scripts/ssd.sh 
------------------------------
 SSD Status:   /dev/sda
 Model     :   Samsung SSD 850 EVO 500GB
------------------------------
 On time:      429d 13h
------------------------------
 Data written:
           MB: 3,793,014.391
           GB: 3,704.115
           TB: 3.617
------------------------------
 Mean write rate:
        MB/hr: 367.932
------------------------------
 Drive health: 99 %
------------------------------

Tu vois, il a été en fonctionnement 1 an et 2 mois (ce qui veut dire beaucoup plus et temps, mon PC de bureau n'étant pas allumé 24/24 !).
Il est à 99% de sa vie.

Autrement dit, le PC lui-même risque de mourir ou être tellement obsolète, que j'en changerai d'ici que le SSD meure...

Tu vois également, c'est un 500Go... c'était pas mal quand je l'ai acheté, maintenant c'est quasiment entrée de gamme comme espace de stockage.
A noter qu'il est monté sur / et sur /home, donc usage "normal" sans chercher à l'économiser. D'ailleurs comme tu vois, il écrit 368Mo/h

Comme les SSD plus récents seront plus gros, et qu'il n'y a pas de raison que ton système écrive plus de données à l'heure, en pratique ça va durer plus longtemps.

Bien sûr les gros fichiers et les trucs assez statiques comme ma collection de photos personnelles sont stockées sur un disque qui tourne, et /tmp est monté en RAM (j'ai 32Go de RAM, donc j'ai mis 20Go de /tmp et ça permet plein de choses !)

A noter que maintenant, même pour les disques qui tournent ils donnent un maxi d'écritures !..

Dernière modification par Zakhar (Le 19/02/2021, à 19:59)

diesel · Le 19/02/2021, à 22:47

https://fr.wikipedia.org/wiki/M%C3%A9moire_flash

Amicalement.

Jean-Marie

truc012 · Le 20/02/2021, à 00:26

Bonjour.
Swap tueur de SSD = Légende urbaine. C'est comme formater plusieurs fois

Déjà le moindre fait d"allumer votre pc sollicite votre SSD. Ubuntu par défaut utilise un tracker qui recherche toutes modifications sur votre système.
Regardez la charge au démarrage entre une Ubuntu par défaut et une via une install mini.

L'histoire des SSD vient du fait qu'à l"poque les clefs USB étaient mal démontées sur Windows et il y avait des risque de corruption .
En 2008 ou à cette époque il y a eu le problème de mise en veille qui a posé des problèmes. Mais il a été vite résolu.

Coeur Noir · Le 20/02/2021, à 03:32

Ubuntu par défaut utilise un tracker qui recherche toutes modifications sur votre système
Dit comme ça, ça fait peur, bouh, un traqueur…

Ta description ( recherche toutes modifications sur votre système ) évoque tracker qu'on peut trouver dans les environnements de bureau Gnome et dérivés, ça s’appellera baloo sous KDE, zeitgeist agit dans les mêmes eaux : ce sont des « indexeurs » de données. Pas un danger en soi, c'est juste une façon supplémentaire de trier ou d’accéder à des fichiers plus rapidement. Ça peut user de la ressource ( avec impact sur les disques où ça lit / écrit ) et on peut s'en passer si on ne trouve pas ça utile, sachant que c'est ± intégré à l'environnement. Ou les paramétrer plus finement pour limiter leur impact.

Ça n'est pas une menace ou une fuite de données comme le nom pourrait vaguement le suggérer. Tous les environnements de bureau n'activent pas par défaut un tel « indexeur ». Probablement que ces services d'indexation ne font pas partie d'une installation minimale, ce qui explique les différences de « charge au démarrage ».

Voir https://doc.ubuntu-fr.org/tracker ⋅ https://doc.ubuntu-fr.org/zeitgeist ⋅ https://community.kde.org/Baloo

Concernant la swap, effectivement ça n'est pas un tueur de SSD et il y a même intérêt à « swapper » sur SSD plutôt que HDD :
⋅ usage historique de la swap : compenser un manque de RAM quand celle-ci est trop sollicitée. Aujourd'hui c'est à priori rare de manquer de RAM, et quand ça arrive, autant swapper sur un disque à lecture écriture rapide plutôt que sur un HDD forcément beaucoup plus lent que la RAM initiale : c'est déjà une peine de manquer de RAM, ne la doublons pas d'une lenteur excessive pour les rares fois où il y aura besoin de swapper.
⋅ usage plus récent de la swap : l'hibernation. Celle-ci consiste à copier tout l'état du système à un moment donné, pour recharger rapidement cet état lors de la sortie d'hibernation. Pour y arriver, Ubuntu copie grosso-modo tout ce qui se trouve en RAM dans la swap. Si le but est la rapidité alors là aussi autant garder la swap sur un SSD - sauf si on craint qu'un usage fréquent de l'hibernation fatigue prématurément ce support.

Caille · Le 20/02/2021, à 12:11

Zakhar a écrit :

Exemple sur mon SSD sur ce PC:
$ sudo ~/Scripts/ssd.sh 
Tu vois, il a été en fonctionnement 1 an et 2 mois (ce qui veut dire beaucoup plus et temps, mon PC de bureau n'étant pas allumé 24/24 !). Il est à 99% de sa vie.

Merci pour vos réponses.

Bonjour Zakhar,

Tu possède un script en bash pour vérifier un SSD, peux-tu le poster ici ~/Scripts/ssd.sh ?
Sous Windows (que je n'utilise presque plus) j'ai accès au logiciel Magician de Samsung, mais pas sous Linux.
Y-a-t-il sous Linux des logiciels pour contrôler son SSD ?

Cordialement.

truc012 · Le 20/02/2021, à 15:23

@Coeur Noir

Mazette tu as bien évolué depuis la première ou nous sommes rencontré mais il te manque un truc.

Coeur Noir · Le 20/02/2021, à 16:51

Bien évolué ? Euh… c'est quoi le rapport avec le sujet de la discussion ?

@caille : voir ente autres https://doc.ubuntu-fr.org/smartmontools

Zakhar · Le 21/02/2021, à 10:18

Caille a écrit :

Bonjour Zakhar,
Tu possède un script en bash pour vérifier un SSD, peux-tu le poster ici ~/Scripts/ssd.sh ?

C'est juste un truc (inspiré d'un post sur internet dont je n'ai plus la source) qui filtre les champs utiles d'une sortie de smartmontools

$ cat ~/Scripts/ssd.sh 
#!/bin/sh

#######################################
# Variables                           #
#######################################

SSD_DEVICE="/dev/sda"

ON_TIME_TAG="  9"
WEAR_COUNT_TAG="177"
LBAS_WRITTEN_TAG="241"
MODEL="Device Model:"
LBA_SIZE=512 # Value in bytes

BYTES_PER_MB=1048576
BYTES_PER_GB=1073741824
BYTES_PER_TB=1099511627776

#######################################
# Get total data written...           #
#######################################

# Get SMART attributes
SMART_INFO=$(sudo /usr/sbin/smartctl -a "$SSD_DEVICE")

# Extract required attributes
DEVICE_MODEL=$(echo "$SMART_INFO" |  sed -n "/^${MODEL}/{s/${MODEL}\s*//;p;q}" )
ON_TIME=$(echo "$SMART_INFO" | sed -n "/^${ON_TIME_TAG}/{s/.* //;p;q}" )
ON_DAYS=$(( $ON_TIME / 24 ))
ON_HOURS=$(( $ON_TIME % 24 ))
WEAR_COUNT=$(echo "$SMART_INFO" |  sed -n "/^${WEAR_COUNT_TAG}/s/.*0x[0-9]*\s*0*\([0-9]*\)\s*.*/\1/p" )
LBAS_WRITTEN=$(echo "$SMART_INFO" | sed -n "/^${LBAS_WRITTEN_TAG}/{s/.* //;p;q}"  )

# Convert LBAs -> bytes
BYTES_WRITTEN=$(( $LBAS_WRITTEN * $LBA_SIZE ))
MB_WRITTEN=$(echo "scale=3; $BYTES_WRITTEN / $BYTES_PER_MB" | bc)
GB_WRITTEN=$(echo "scale=3; $BYTES_WRITTEN / $BYTES_PER_GB" | bc)
TB_WRITTEN=$(echo "scale=3; $BYTES_WRITTEN / $BYTES_PER_TB" | bc)

# Output results...
echo "------------------------------"
echo " SSD Status:   $SSD_DEVICE"
echo " Model     :   $DEVICE_MODEL"
echo "------------------------------"
if [ $ON_DAYS -eq 0 ]; then
  echo " On time:      ${ON_HOURS}h"
else
  echo " On time:      ${ON_DAYS}d ${ON_HOURS}h"
fi
echo "------------------------------"
echo " Data written:"
echo "           MB: $(echo $MB_WRITTEN | sed ':a;s/\B[0-9]\{3\}\>/,&/;ta')"
echo "           GB: $(echo $GB_WRITTEN | sed ':a;s/\B[0-9]\{3\}\>/,&/;ta')"
echo "           TB: $(echo $TB_WRITTEN | sed ':a;s/\B[0-9]\{3\}\>/,&/;ta')"
echo "------------------------------"
echo " Mean write rate:"
echo "        MB/hr: $(echo "scale=3; $MB_WRITTEN / $ON_TIME" | bc | sed ':a;s/\B[0-9]\{3\}\>/,&/;ta')"
echo "------------------------------"
echo " Drive health: ${WEAR_COUNT} %"
echo "------------------------------"

Il faut adapter les variables du début (jusqu'à LBA_SIZE) à votre usage.
Le script ci-dessus fonctionne pour un Samsung.
J'ai d'autres marques et il faut adapter un peu les "tags" qu'on récupère parce que malheureusement il n'y a pas de norme stricte sur ce qu'on trouve à quel endroit dans les "tags" de smartctl.

Dernière modification par Zakhar (Le 21/02/2021, à 10:21)

Zakhar · Le 21/02/2021, à 10:47

truc012 a écrit :

Bonjour.
Swap tueur de SSD = Légende urbaine. C'est comme formater plusieurs fois

Avec un processeur assez rapide et beaucoup de RAM (j'ai monté exprès 32Go sur mon PC de bureau... et hésité avec 64Go, mais à l'époque c'était encore un peu cher 64Go), vous avez l'option de la zram.

J'ai "bricolé" le truc, qui normalement prend la moitié de la RAM en zram pour qu'il ne prenne que 1/4.

Ainsi la priorité de swap, la première chose qui sera utilisée en swap, avant l'écriture sur disque physique, est la swap en ZRAM.

Démonstration :

$ swapon
NAME       TYPE        SIZE USED PRIO
/dev/sda2  partition   7,6G   0B   -2
/dev/sdb3  partition   4,5G   0B   -3
/dev/zram0 partition 999,1M 4,4M    5
/dev/zram1 partition 999,1M 4,4M    5
/dev/zram2 partition 999,1M 4,2M    5
/dev/zram3 partition 999,1M 4,1M    5
/dev/zram4 partition 999,1M   4M    5
/dev/zram5 partition 999,1M 4,1M    5
/dev/zram6 partition 999,1M 4,3M    5
/dev/zram7 partition 999,1M   4M    5

Vous voyez, le système a eu besoin d'un tout petit peu de swap (autour de 32Mo sur l'exemple) et il a tout mis en RAM.

L'ordre de swap ci-dessus est donc : la RAM, le SSD (/dev/sda) puis le HDD (/dev/sdb)

Comme Linux gère la mémoire en "virtuel", on peut sur-souscrire la mémoire sans problème, elle ne sera réellement utilisée que quand le système en a besoin.

Le 'bricolage' au quart de la RAM était nécessaire pour laisser le montage /tmp s'étendre aux 20Go alloué. Ainsi j'ai 20Go de /tmp, 8Go de swap en RAM et ça laisse 4Go pour les programmes, ce qui est en principe large avec Linux. Bien sûr, l'utilisation des 20Go de /tmp n'est pas permanente, donc aux moments où le /tmp est pas ou peu utilisé, c'est de la mémoire disponible pour les programme et leur données.

Donc n'hésitez pas à mettre plein de RAM, c'est toujours très utile !

Dernière modification par Zakhar (Le 21/02/2021, à 10:52)

Coeur Noir · Le 21/02/2021, à 17:41

Euh oui pourquoi pas… la swap à l'origine c'est pour éviter au système de complètement figer, faute de RAM.
Là comme t'es confort en RAM, tu crées un « tampon » compressé ( zram ) pour swapper dans cette même RAM, et comme ça c'est vraiment en dernier ressort que la swap finira quand même inéluctablement ailleurs, sur disque, si ta RAM venait à se remplir.

D'où la remarque initiale : aujourd'hui c'est assez rare d'avoir besoin de « swapper » faute de RAM - donc on peut la laisser en fichier sur un SSD ( puisque servira rarement ).
C'est plutôt pour ceux qui utilisent l'hibernation qu'elle est importante et comment se comporte ton truc, Zakhar, avec l'hibernation ? Je dirais : mal, puisque l'hibernation a besoin d'un stockage qui résiste à la déconnexion ( nécessite une swap « physique » en quelque sorte ).

Dernière modification par Coeur Noir (Le 21/02/2021, à 17:43)

Caille · Le 22/02/2021, à 19:03

Zakhar a écrit :

C'est juste un truc (inspiré d'un post sur internet dont je n'ai plus la source) qui filtre les champs utiles d'une sortie de smartmontools
$ cat ~/Scripts/ssd.sh 
#!/bin/sh

#######################################
# Variables                           #
#######################################

SSD_DEVICE="/dev/sda"

ON_TIME_TAG="  9"
WEAR_COUNT_TAG="177"
LBAS_WRITTEN_TAG="241"
MODEL="Device Model:"
LBA_SIZE=512 # Value in bytes

BYTES_PER_MB=1048576
BYTES_PER_GB=1073741824
BYTES_PER_TB=1099511627776

#######################################
Il faut adapter les variables du début (jusqu'à LBA_SIZE) à votre usage.
Le script ci-dessus fonctionne pour un Samsung.
J'ai d'autres marques et il faut adapter un peu les "tags" qu'on récupère parce que malheureusement il n'y a pas de norme stricte sur ce qu'on trouve à quel endroit dans les "tags" de smartctl.

Bonjour Zakhar,

Je possède un Samsung 860 Pro de 1 To avec plusieurs partitions Linux et une Windows (signature) en sda c'est quoi qu'il faut adapter comme variable ?

Boot-infos: https://paste.ubuntu.com/p/CrGT2Zw5yY/

Dernière modification par Caille (Le 22/02/2021, à 19:09)

Zakhar · Le 22/02/2021, à 20:19

Caille a écrit :

Je possède un Samsung 860 Pro de 1 To avec plusieurs partitions Linux et une Windows (signature) en sda c'est quoi qu'il faut adapter comme variable ?

Sans doute aucune, puisqu'il est sur sda comme chez moi, et c'est la même marque.
Regarde ce que ça donne si c'est "vraisemblable".

Sinon il faut regarder la sortie d'un smartctl pour adapter si les chiffres te semblent farfelus.

Coeur Noir a écrit :

D'où la remarque initiale : aujourd'hui c'est assez rare d'avoir besoin de « swapper » faute de RAM - donc on peut la laisser en fichier sur un SSD ( puisque servira rarement ).
C'est plutôt pour ceux qui utilisent l'hibernation qu'elle est importante et comment se comporte ton truc, Zakhar, avec l'hibernation ? Je dirais : mal, puisque l'hibernation a besoin d'un stockage qui résiste à la déconnexion ( nécessite une swap «
physique » en quelque sorte ).

Exact, mais je n'utilise pas l'hibernation.
Depuis la 20.04 mon PC démarre en moins de 30 secondes dont une dizaine dû au PC lui-même (UEFI + lancement des disques rotatifs). Donc au niveau temps, je ne gagnerais absolument rien à hiberner, bien au contraire ce serait sans doute bien plus long !.. Ce que je pourrais gagner, c'est de pouvoir mettre en sommeil des tâches longues, mais à part de temps en temps quelques conversions de films, je n'ai guère de tâches de ce genre. Aussi je pourrais dans ce cas utiliser simplement la mise en veille, la différence est alors un peu d'électricité.

Donc je n'ai pas prévu de swap (disque) à la taille de ma RAM, parce utiliser l'hibernation n'est pas dans mes intentions proches. Si je changeais d'avis, j'imagine que je pourrais toujours mettre un fichier swap sur un disque rotatif...

P.S.: la groooosse RAM est super pratique. Par exemple la dernière conversion d'un film mkv autour de 8Go vers mp4 autour de 6Go, j'ai tout fait en RAM. Comme ça : pas d'usure du SSD, ni du HDD.
Du reste, avec ma super config, j'ai fait un "whiler" (un script avec un "while") qui met le HDD en standby si pas utilisé au bout de 10 minutes. Outre éviter de le faire tourner pour rien, ça fait moins de bruit. Mon PC étant très silencieux (c'était un des critères quand je l'ai monté), j'entends légèrement le HDD quand il est en rotation, et son arrêt fait du bien aux oreilles. J'ai bien sûr un "lanceur" pour redémarrer le HDD au besoin.

Dernière modification par Zakhar (Le 22/02/2021, à 20:31)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 19/02/2021, à 18:59

SSD et obsolescence programmée ?

#2 Le 19/02/2021, à 19:55

Re : SSD et obsolescence programmée ?

#3 Le 19/02/2021, à 22:47

Re : SSD et obsolescence programmée ?

#4 Le 20/02/2021, à 00:26

Re : SSD et obsolescence programmée ?

#5 Le 20/02/2021, à 03:32

Re : SSD et obsolescence programmée ?

#6 Le 20/02/2021, à 12:11

Re : SSD et obsolescence programmée ?

#7 Le 20/02/2021, à 15:23

Re : SSD et obsolescence programmée ?

#8 Le 20/02/2021, à 16:51

Re : SSD et obsolescence programmée ?

#9 Le 21/02/2021, à 10:18

Re : SSD et obsolescence programmée ?

#10 Le 21/02/2021, à 10:47

Re : SSD et obsolescence programmée ?

#11 Le 21/02/2021, à 17:41

Re : SSD et obsolescence programmée ?

#12 Le 22/02/2021, à 19:03

Re : SSD et obsolescence programmée ?

#13 Le 22/02/2021, à 20:19

Re : SSD et obsolescence programmée ?

Pied de page des forums