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) ?
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: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
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 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.
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 <https://crystalmark.info/en/software/crystaldiskinfo/>
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) ?
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 <https://crystalmark.info/en/software/crystaldiskinfo/>
pehache
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 <https://crystalmark.info/en/software/crystaldiskinfo/>
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
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) ?
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 <https://crystalmark.info/en/software/crystaldiskinfo/>
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 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
-- "...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
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
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
-- "...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 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.
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.
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 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
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
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 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.
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.
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 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.
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.
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 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.
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.
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 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.
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.
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 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.
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.
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.
