vieux SSD (trim, usure...)

Le
pehache
fu2 fr.comp.stockage, mais je rameute un peu ailleurs !

Bonjour,

J'ai récupéré un Thinkpad X301 de réforme au boulot (superbe machine,
qui ne fait pas ses 10 ans), et je lui ai collé xubuntu 18.04 à la
place de W7.

Ce X301 a un SSD de 128Go, et surprise, xubuntu (ou plutôt hdparm) me dit
que ce SSD ne supporte pas le TRIM (plus exactement rien ne montre qu'il le
supporte, voir output hdparm ci-dessous Je dis surprise car W7 quant à
lui me rapportait que le TRIM était activé : faut-il supposer que W7
envoie les commandes TRIM dans tous les cas sans se préoccuper du support
effectif par le SSD ? En fait je vois que xubuntu planifie quand même
fstrim

Qu'en penser ? Est-ce que l'absence de mention du TRIM dans hdparm signifie
avec certitude qu'il n'est pas supporté ? Si oui, existe-t-il des choses
à faire pour pour pallier au moins en partie à cette absence ?

Autre chose, je voudrais avoir une idée de l'état d'usure de ce SSD. J'ai
toujours un peu de mal à interpréter les données SMART, que vous inspire
le rapport posté ci-dessous (en dessous de l'output hdparm) ?



sudo hdparm -I /dev/sda

/dev/sda:

ATA device, with non-removable media
Model Number: SAMSUNG MMCQE28G8MUP-0VA
Serial Number: SE838A4134
Firmware Revision: VAM08L1Q
Standards:
Used: ATA/ATAPI-7 T13 1532D revision 1
Supported: 7 6 5 4
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBA user addressable sectors: 250069680
LBA48 user addressable sectors: 250069680
Logical Sector size: 512 bytes
Physical Sector size: 512 bytes
device size with M = 1024*1024: 122104 MBytes
device size with M = 1000*1000: 128035 MBytes (128 GB)
cache/buffer size = unknown
Nominal Media Rotation Rate: Solid State Device
Capabilities:
LBA, IORDY(can be disabled)
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 16 Current = 16
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
Cycle time: min0ns recommended0ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control0ns IORDY flow control0ns
Commands/features:
Enabled Supported:
* SMART feature set
Security Mode feature set
* Power Management feature set
* Write cache
* Look-ahead
* Host Protected Area feature set
* WRITE_BUFFER command
* READ_BUFFER command
* DOWNLOAD_MICROCODE
SET_MAX security extension
* 48-bit Address feature set
* Device Configuration Overlay feature set
* Mandatory FLUSH_CACHE
* FLUSH_CACHE_EXT
* SMART error logging
* SMART self-test
* General Purpose Logging feature set
* WRITE_{DMA|MULTIPLE}_FUA_EXT
* WRITE_UNCORRECTABLE_EXT command
* Gen1 signaling speed (1.5Gb/s)
* Gen2 signaling speed (3.0Gb/s)
* Host-initiated interface power management
* Phy event counters
Device-initiated interface power management
* Software settings preservation
Security:
Master password revision code = 65534
supported
not enabled
not locked
frozen
not expired: security count
supported: enhanced erase
6min for SECURITY ERASE UNIT. 6min for ENHANCED SECURITY ERASE UNIT.
Checksum: correct



== sudo smartctl -a /dev/sda ==

smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.15.0-43-generic] (local
build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

START OF INFORMATION SECTION
Device Model: SAMSUNG MMCQE28G8MUP-0VA
Serial Number: SE838A4134
Firmware Version: VAM08L1Q
User Capacity: 128 035 676 160 bytes [128 GB]
Sector Size: 512 bytes logical/physical
Rotation Rate: Solid State Device
Device is: Not in smartctl database [for details use: -P showall]
ATA Version is: ATA/ATAPI-7 T13/1532D revision 1
Local Time is: Sat Jan 19 19:02:05 2019 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

START OF READ SMART DATA SECTION
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status: (0x02) Offline data collection activity
was completed without error.
Auto Offline Data Collection: Disabled.
Self-test execution status: ( 0) The previous self-test routine
completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: ( 360) seconds.
Offline data collection
capabilities: (0x5b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
No Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 6) minutes.
Extended self-test routine
recommended polling time: ( 36) minutes.

SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED
WHEN_FAILED RAW_VALUE
9 Power_On_Hours 0x0032 095 095 000 Old_age Always
- 22383
12 Power_Cycle_Count 0x0032 096 096 000 Old_age Always
- 3766
175 Program_Fail_Count_Chip 0x0032 100 100 011 Old_age Always
- 0
176 Erase_Fail_Count_Chip 0x0032 100 100 011 Old_age Always
- 0
177 Wear_Leveling_Count 0x0013 098 098 023 Pre-fail Always
- 1314
178 Used_Rsvd_Blk_Cnt_Chip 0x0013 084 084 011 Pre-fail Always
- 19
179 Used_Rsvd_Blk_Cnt_Tot 0x0013 099 099 010 Pre-fail Always
- 37
180 Unused_Rsvd_Blk_Cnt_Tot 0x0013 099 099 010 Pre-fail Always
- 3867
181 Program_Fail_Cnt_Total 0x0032 100 100 010 Old_age Always
- 0
182 Erase_Fail_Count_Total 0x0032 100 100 010 Old_age Always
- 0
183 Runtime_Bad_Block 0x0013 100 100 010 Pre-fail Always
- 0
187 Reported_Uncorrect 0x0033 100 100 000 Pre-fail Always
- 0
195 Hardware_ECC_Recovered 0x001a 200 200 000 Old_age Always
- 0
198 Offline_Uncorrectable 0x0030 100 100 000 Old_age Offline
- 0
199 UDMA_CRC_Error_Count 0x003e 253 253 000 Old_age Always
- 0
233 Media_Wearout_Indicator 0x003a 001 001 000 Old_age Always
- 10074461
234 Unknown_Attribute 0x0012 100 100 000 Old_age Always
- 0
235 Unknown_Attribute 0x0012 100 100 000 Old_age Always
- 0
236 Unknown_Attribute 0x0012 099 099 000 Old_age Always
- 1507
237 Unknown_Attribute 0x0012 099 099 000 Old_age Always
- 1794
238 Unknown_Attribute 0x0012 100 100 000 Old_age Always
- 0

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours)
LBA_of_first_error
# 1 Short offline Completed without error 00% 22382
-

SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Calimero
Le #26506063
Le 19/01/2019 à 19:04, pehache a écrit :
fu2 fr.comp.stockage, mais je rameute un peu ailleurs !
Bonjour,
J'ai récupéré un Thinkpad X301 de réforme au boulot (superbe machine,
qui ne fait pas ses 10 ans...), et je lui ai collé xubuntu 18.04 à la
place de W7.
Ce X301 a un SSD de 128Go, et surprise, xubuntu (ou plutôt hdparm) me dit
que ce SSD ne supporte pas le TRIM (plus exactement rien ne montre qu'il le
supporte, voir output hdparm ci-dessous... Je dis surprise car W7 quant à
lui me rapportait que le TRIM était activé : faut-il supposer que W7
envoie les commandes TRIM dans tous les cas sans se préoccuper du support
effectif par le SSD ? En fait je vois que xubuntu planifie quand même
fstrim...
Qu'en penser ? Est-ce que l'absence de mention du TRIM dans hdparm signifie
avec certitude qu'il n'est pas supporté ? Si oui, existe-t-il des choses
à faire pour pour pallier au moins en partie à cette absence ?
Autre chose, je voudrais avoir une idée de l'état d'usure de ce SSD. J'ai
toujours un peu de mal à interpréter les données SMART, que vous inspire
le rapport posté ci-dessous (en dessous de l'output hdparm) ?

===================== sudo hdparm -I /dev/sda ====================

Vu que ta posté sur windows ,un utilitaire sous windows
pehache
Le #26506067
Le 20/01/2019 à 11:04, Calimero a écrit :
Le 19/01/2019 à 19:04, pehache a écrit :
fu2 fr.comp.stockage, mais je rameute un peu ailleurs !
Bonjour,
J'ai récupéré un Thinkpad X301 de réforme au boulot (superbe machine,
qui ne fait pas ses 10 ans...), et je lui ai collé xubuntu 18.04 à la
place de W7.
Ce X301 a un SSD de 128Go, et surprise, xubuntu (ou plutôt hdparm) me dit
que ce SSD ne supporte pas le TRIM (plus exactement rien ne montre
qu'il le
supporte, voir output hdparm ci-dessous... Je dis surprise car W7 quant à
lui me rapportait que le TRIM était activé : faut-il supposer que W7
envoie les commandes TRIM dans tous les cas sans se préoccuper du support
effectif par le SSD ? En fait je vois que xubuntu planifie quand même
fstrim...
Qu'en penser ? Est-ce que l'absence de mention du TRIM dans hdparm
signifie
avec certitude qu'il n'est pas supporté ? Si oui, existe-t-il des choses
à faire pour pour pallier au moins en partie à cette absence ?
Autre chose, je voudrais avoir une idée de l'état d'usure de ce SSD. J'ai
toujours un peu de mal à interpréter les données SMART, que vous inspire
le rapport posté ci-dessous (en dessous de l'output hdparm) ?

===================== sudo hdparm -I /dev/sda ==================== >

Vu que ta posté sur windows ,un utilitaire sous windows


Il n'y plus Windows sur ce PC, j'ai posté sur le groupe Windows parce
que W7 (quand il était installé) rapportait que le TRIM était activé...
--
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes.", ST sur fr.bio.medecine
pehache
Le #26506075
Le 19/01/2019 à 19:04, pehache a écrit :
Autre chose, je voudrais avoir une idée de l'état d'usure de ce SSD. J'ai
toujours un peu de mal à interpréter les données SMART, que vous inspire
le rapport posté ci-dessous (en dessous de l'output hdparm) ?

Je précise ma pensée sur ce point...
La partie inquiétante du rapport SMART est la ligne 233 : il s'agit
apparemment du volume cumulé d'écritures, avec une valeur normalisée qui
tombe à 1 quand le volume max "garanti" par le fabricant a été atteint ?
Là il le serait donc.
Par contre les lignes 178/179/180 semblent concerner les blocs de
réserves pour remplacer les blocs défectueux ? Le nombre de blocs
utilisés est de 19 ou 37 (je ne comprends pas trop la différence entre
les lignes 178 et 179), alors que le nombre de blocs inutilisés est de
3867 (ligne 180) ? Si oui il y a de la marge (bien que je suppose que ça
aller très vite quand tous les blocs atteignent la "limite d'âge")...
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED
WHEN_FAILED RAW_VALUE
178 Used_Rsvd_Blk_Cnt_Chip 0x0013 084 084 011 Pre-fail Always
- 19
179 Used_Rsvd_Blk_Cnt_Tot 0x0013 099 099 010 Pre-fail Always
- 37
180 Unused_Rsvd_Blk_Cnt_Tot 0x0013 099 099 010 Pre-fail Always
- 3867
233 Media_Wearout_Indicator 0x003a 001 001 000 Old_age Always
- 10074461

--
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes.", ST sur fr.bio.medecine
Pascal Hambourg
Le #26506210
Le 19/01/2019 à 19:04, pehache a écrit :
J'ai récupéré un Thinkpad X301 de réforme au boulot (superbe machine,
qui ne fait pas ses 10 ans...), et je lui ai collé xubuntu 18.04 à la
place de W7.
Ce X301 a un SSD de 128Go, et surprise, xubuntu (ou plutôt hdparm) me dit
que ce SSD ne supporte pas le TRIM (plus exactement rien ne montre qu'il le
supporte, voir output hdparm ci-dessous.

(...)
Model Number: SAMSUNG MMCQE28G8MUP-0VA
Serial Number: SE838A4134
Firmware Revision: VAM08L1Q

Les résultats d'une recherche sur le web avec ce modèle me laissent
penser qu'effectivement il ne supporte pas le TRIM.
pehache
Le #26506221
Le 20/01/2019 à 23:03, Pascal Hambourg a écrit :
Le 19/01/2019 à 19:04, pehache a écrit :
J'ai récupéré un Thinkpad X301 de réforme au boulot (superbe machine,
qui ne fait pas ses 10 ans...), et je lui ai collé xubuntu 18.04 à la
place de W7.
Ce X301 a un SSD de 128Go, et surprise, xubuntu (ou plutôt hdparm) me dit
que ce SSD ne supporte pas le TRIM (plus exactement rien ne montre
qu'il le
supporte, voir output hdparm ci-dessous.

(...)
    Model Number:       SAMSUNG MMCQE28G8MUP-0VA
    Serial Number:      SE838A4134
    Firmware Revision:  VAM08L1Q

Les résultats d'une recherche sur le web avec ce modèle me laissent
penser qu'effectivement il ne supporte pas le TRIM.

Ce qui m'étonnait c'était que ses performances en écriture étaient
correctes après toutes ces années, malgré l'absence de TRIM.
En cherchant de mon côté, il semble que ces anciens SSD Samsung avaient
un Garbage Collector assez performant, mais qui fonctionne uniquement si
le SSD est formaté en NTFS ! Je suppose que le contrôleur lui-même sait
lire les tables d'allocation de fichiers NTFS et peut donc connaître les
secteurs libres par ce biais.
Problème : sous Linux ce GC intégré ne marchera plus :-(
Je suis bon pour remplacer le SSD je crois, mais c'est du 1,8" quasiment
introuvable aujourd'hui. Il faut apparemment prendre du mSATA avec un
adaptateur, en espérant qu'il n'y ait pas de mauvaise surprise (genre le
SSD d'origine plus petit que l'adaptateur...)
--
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes.", ST sur fr.bio.medecine
Pascal Hambourg
Le #26506369
Le 21/01/2019 à 00:30, pehache a écrit :
Ce qui m'étonnait c'était que ses performances en écriture étaient
correctes après toutes ces années, malgré l'absence de TRIM.

Avec quel volume d'écriture ?
L'écriture est rapide tant qu'il y a des blocs libres. Le TRIM facilite
le garbage collector mais n'est pas indispensable. Sans TRIM, un garbage
collector "agressif" est néanmoins un facteur aggravant d'amplification
d'écriture. Une partie plus ou moins importante de la mémoire flash
brute est réservée pour le garbage collector. Dans un SSD de 120 Go de
capacité utile, on peut supporter que la capacité brute est de 137 Go
(128 Gio) donc la réserve est de 137 - 120 = 17 Go. Ça permet de voir venir.
En cherchant de mon côté, il semble que ces anciens SSD Samsung avaient
un Garbage Collector assez performant, mais qui fonctionne uniquement si
le SSD est formaté en NTFS ! Je suppose que le contrôleur lui-même sait
lire les tables d'allocation de fichiers NTFS et peut donc connaître les
secteurs libres par ce biais.
Problème : sous Linux ce GC intégré ne marchera plus :-(

Pire : ce genre d'optimisation est connu pour avoir causé des pertes de
données en effaçant des blocs que le contrôleur intégré croyait non
utilisés.
Pascal Hambourg
Le #26506368
Le 21/01/2019 à 20:30, Pascal Hambourg a écrit :
Une partie plus ou moins importante de la mémoire flash
brute est réservée pour le garbage collector. Dans un SSD de 120 Go de
capacité utile, on peut supporter que la capacité brute est de 137 Go
(128 Gio) donc la réserve est de 137 - 120 = 17 Go. Ça permet de voir
venir.

Correction : ce modèle a une capacité utile de 128 Go, donc la réserve
ne serait que de 9 Go.
pehache
Le #26506402
Le 21/01/2019 à 20:30, Pascal Hambourg a écrit :
Le 21/01/2019 à 00:30, pehache a écrit :
tt
Ce qui m'étonnait c'était que ses performances en écriture étaient
correctes après toutes ces années, malgré l'absence de TRIM.

Avec quel volume d'écriture ?

En 10 ans on peut supposer que tous les blocs ont été écrits au moins
une fois :-)
L'écriture est rapide tant qu'il y a des blocs libres. Le TRIM facilite
le garbage collector mais n'est pas indispensable. Sans TRIM, un garbage
collector "agressif" est néanmoins un facteur aggravant d'amplification
d'écriture. Une partie plus ou moins importante de la mémoire flash
brute est réservée pour le garbage collector. Dans un SSD de 120 Go de
capacité utile, on peut supporter que la capacité brute est de 137 Go
(128 Gio) donc la réserve est de 137 - 120 = 17 Go. Ça permet de voir
venir.

J'ai découvert avec ce SSD le principe du GC qui infère les secteurs
libres en lisant les tables d'allocations du système de fichiers (ou un
truc dans le genre). Avant ça je ne voyais pas comment un GC pouvait
fonctionner sans TRIM.
Pascal Hambourg
Le #26506405
Le 21/01/2019 à 23:36, pehache a écrit :
Le 21/01/2019 à 20:30, Pascal Hambourg a écrit :
Le 21/01/2019 à 00:30, pehache a écrit :
tt
Ce qui m'étonnait c'était que ses performances en écriture étaient
correctes après toutes ces années, malgré l'absence de TRIM.

Avec quel volume d'écriture ?

En 10 ans on peut supposer que tous les blocs ont été écrits au moins
une fois :-)

Je ne parle pas du volume total de toute la vie du SSD mais du volume
d'écriture mis en jeu lors de ta mesure de performance. Si ce volume est
inférieur à la réserve de blocs libres, il n'y a aucune raison que les
performances en écriture soient affectées.
pehache
Le #26506449
Le 22/01/2019 à 00:25, Pascal Hambourg a écrit :
Le 21/01/2019 à 23:36, pehache a écrit :
Le 21/01/2019 à 20:30, Pascal Hambourg a écrit :
Le 21/01/2019 à 00:30, pehache a écrit :
tt
Ce qui m'étonnait c'était que ses performances en écriture étaient
correctes après toutes ces années, malgré l'absence de TRIM.

Avec quel volume d'écriture ?

En 10 ans on peut supposer que tous les blocs ont été écrits au moins
une fois :-)

Je ne parle pas du volume total de toute la vie du SSD mais du volume
d'écriture mis en jeu lors de ta mesure de performance. Si ce volume est
inférieur à la réserve de blocs libres, il n'y a aucune raison que les
performances en écriture soient affectées.


Je reprends :-) : je ne voyais pas comment du point de vue du contrôleur
il pouvait y avoir des blocs libres après quelque temps d'utilisation sans
TRIM.
Publicité
Poster une réponse
Anonyme