web-dev-qa-db-fra.com

Samsung SSD "Wear_Leveling_Count" signification

J'ai des SSD Samsung sur mon propre ordinateur portable et sur certains serveurs.

Quand je fais:

smartctl -a /dev/sda | grep 177

J'obtiens des résultats que je ne peux pas comprendre. Voici quelques exemples:

# my laptop Samsung SSD 850 EVO 500GB (new)
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
177 Wear_Leveling_Count     0x0013   100   100   000    Pre-fail  Always       -       0

# server 256 GB, SAMSUNG MZ7TE256HMHP-00000
177 Wear_Leveling_Count     0x0013   095   095   000    Pre-fail  Always       -       95

# server 512 GB, SAMSUNG MZ7TE512HMHP-00000 (1 year old)
177 Wear_Leveling_Count     0x0013   099   099   000    Pre-fail  Always       -       99

# server 512 GB, SAMSUNG MZ7TE512HMHP-00000 (suppose to be new)
177 Wear_Leveling_Count     0x0013   099   099   000    Pre-fail  Always       -       99

# server 480 GB, SAMSUNG MZ7KM480HAHP-0E005
177 Wear_Leveling_Count     0x0013   099   099   005    Pre-fail  Always       -       3

# server 240 GB, SAMSUNG MZ7KM240HAGR-0E005
177 Wear_Leveling_Count     0x0013   099   099   005    Pre-fail  Always       -       11

Une idée de comment lire Wear_Leveling_Count?

Certaines valeurs sont au minimum, d'autres au maximum.

Si considérer "ordinateur portable" Samsung SSD 850 EVO 500GB, il est 0 et va probablement aller à 100, puis échouera.

Si envisagez d'abord "serveur" 256 GB, SAMSUNG MZ7TE256HMHP-00000, est-il déjà au maximum? Va-t-il descendre à zéro?

ssdsmart
23
Nick

Kingston décrit cet attribut SMART comme suit:

Nombre de cycles d'effacement/programme par bloc en moyenne. Cet attribut est destiné à être un indicateur d'usure imminente. Équation normalisée: 100 - (100 * nombre d'effacements moyen/nombre nominal maximal de cycles d'effacement NAND)

Ignorez le Raw Data dans ces cas (ils peuvent être manipulés par des fabricants pour fonctionner de différentes manières) et regardez la colonneCurrent Value.

Cette source de Anandtech nous donne une bonne indication sur la façon d'utiliser cette figure:

La valeur de compte d'usure (WLC) SMART nous donne toutes les données dont nous avons besoin. La valeur actuelle représente l’endurance restante du lecteur en pourcentage, ce qui signifie qu’elle commence à 100 et diminue linéairement au fur et à mesure de l’écriture du lecteur. La valeur WLC brute compte les cycles P/E consommés. Par conséquent, si ces deux valeurs sont surveillées lors de l'écriture sur le lecteur, nous trouverons plus tôt que plus tard l'emplacement où la valeur normalisée chute de un.

Tous vos lecteurs sont compris entre 95 et 100 et finiront par tomber à 0. Il s'agit d'une estimation du nombre de cycles write, erase, rewrite etc. que chaque bloc peut exécuter avant de tomber en panne, et pour l'instant l'un de vos lecteurs. estestiméavoir utilisé 5% de sa durée de vie prévue actuelle. Encore une fois, le mot clé ici est estimé.

Notez également que vos disques peuvent utiliser différentes technologies NAND, d’où les différences de vie perçue. Certaines technologies NAND prévoient que les blocs dureront environ 1 000 cycles PE chacun, tandis que d’autres peuvent atteindre 30 000 cycles.

40
Jonno

SMART signale une condition PREFAILED pour mon Samsung SM951 (AHCI) 128 Go, signalée sous Linux sous la forme SAMSUNG MZHPV128HDGM-00000 (BXW2500Q).

Mais dans mon cas, je pense que c'est un bug du firmware du lecteur,

  • parce que la propriété total-bytes-written est signalée à 1,1 To alors que le lecteur a un nombre total d'octets écrits (TBW) spécifié de 75 To! Ce qui est probablement du côté (très) salvateur, car des disques similaires (MLC NAND) ont tous atteint une multitude de ceux-ci (600 To) dans un véritable test d'endurance ,
  • et mis à part l'avertissement wear_level_count, aucune autre erreur ni aucun autre avertissement préalable ou ancien n'est signalé,
  • alors que le reallocated-sector-count, qui selon ce test est un bon indicateur de pré-échec, est toujours 0.

Mon conseil serait donc d'examiner ces valeurs pour votre lecteur/système et de baser vos conclusions sur cela.

Je préfère l'utilitaire de bas niveau skdump qui est fourni avec libatasmart, la même bibliothèque que celle utilisée par Gnome Disks .

Utilisez la commande suivante, en remplaçant /dev/sdc par le chemin d'accès à votre périphérique de blocage:

Sudo skdump /dev/sdc

1
Ronald