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.

  • Partager ce contenu :
Vos réponses Page 2 / 2
Trier par : date / pertinence
Pascal Hambourg
Le #26506585
Le 22/01/2019 à 11:00, pehache a écrit :
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.

C'est le boulot du garbage collector de rassembler les données à jour et
d'effacer des blocs ne contenant que des données périmées. Et il n'a pas
forcément besoin de TRIM ni de savoir lire le système de fichiers pour
fonctionner, s'il dispose de suffisamment de blocs supplémentaires qui
ne sont pas comptés dans la capacité visible.
pehache
Le #26506611
Le 23/01/2019 à 00:33, Pascal Hambourg a écrit :
Le 22/01/2019 à 11:00, pehache a écrit :
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.

C'est le boulot du garbage collector de rassembler les données à jour et
d'effacer des blocs ne contenant que des données périmées.

J'ai bien compris et ça je le savais déjà.
Et il n'a pas
forcément besoin de TRIM ni de savoir lire le système de fichiers pour
fonctionner, s'il dispose de suffisamment de blocs supplémentaires qui
ne sont pas comptés dans la capacité visible.

Moui... j'avoue que ce n'est pas hyper clair pour moi, même si je crois
voir comment...
En pratique sur ce SSD qui a déjà été utilisé 10 ans et dont je n'ai
aucune idée de l'état des blocs libres du point de vue du contrôleur,
pour repartir sur un bon pied il faudrait il faudrait pouvoir le
remettre à zéro avant de repartionner en limitant (par exemple) à 100Go
sur les 128Go visibles...
Je vais essayer avec l'utilitaire Samsung pour ce SSD (j'ai déjà tenté
de l'utiliser pour flasher le firmware du SSD avec une version qui amène
le TRIM, mais sans succès. A voir pour l'effacement).
--
"...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 #26506889
Le 23/01/2019 à 08:34, pehache a écrit :
Et il n'a pas
forcément besoin de TRIM ni de savoir lire le système de fichiers pour
fonctionner, s'il dispose de suffisamment de blocs supplémentaires qui
ne sont pas comptés dans la capacité visible.

Moui... j'avoue que ce n'est pas hyper clair pour moi, même si je crois
voir comment...

Oui en fait c'est assez évident, je ne sais pas pourquoi je "bloquais"
là-dessus. Le GC a besoin d'espace libre pour faire son boulot, peu
importe que cet espace ait été "libéré" par le TRIM ou qu'il vienne
d'un pool réservé.
En pratique sur ce SSD qui a déjà été utilisé 10 ans et dont je n'ai
aucune idée de l'état des blocs libres du point de vue du contrôleur,
pour repartir sur un bon pied il faudrait il faudrait pouvoir le
remettre à zéro avant de repartionner en limitant (par exemple) à 100Go
sur les 128Go visibles...
Je vais essayer avec l'utilitaire Samsung pour ce SSD (j'ai déjà tenté
de l'utiliser pour flasher le firmware du SSD avec une version qui amène
le TRIM, mais sans succès. A voir pour l'effacement).

Bah, c'était la mauvaise idée du jour... L'effacement s'est passé
normalement (du moins l'utilitaire n'a pas rapporté de problème), mais le
PC (un Thinkpad X301 je rappelle) est "à moitié brické" après ça :-(
Quand je l'allume il ne se passe rien (même à l'écran) pendant 10mn (!),
puis un message d'erreur est brièvement affiché (pendant 2s, je l'ai
veillé pour le photographier) :
"tpm tpm0: A TPM error(2B) occured continue selftest"
"tpm tpm0: TPM self test failed""
Après ça il boote s'il trouve un support externe bootable, sinon il dit
qu'il ne trouve aucun OS (donc le SSD a bien subi un effacement). En
bootant sur une clef d'installation de xubuntu, je ne vois pas du tout le
SSD (il n'est même pas proposé pour l'installation).
A aucun moment je n'ai l'opportunité d'entrer dans le BIOS. Si j'enlève
le SSD du PC le comportement est exactement le même.
Me voilà bien...
Pascal Hambourg
Le #26506910
Le 24/01/2019 à 19:16, pehache a écrit :
Le 23/01/2019 à 08:34, pehache a écrit :
Et il n'a pas
forcément besoin de TRIM ni de savoir lire le système de fichiers pour
fonctionner, s'il dispose de suffisamment de blocs supplémentaires qui
ne sont pas comptés dans la capacité visible.

Moui... j'avoue que ce n'est pas hyper clair pour moi, même si je crois
voir comment...

Oui en fait c'est assez évident, je ne sais pas pourquoi je "bloquais"
là-dessus. Le GC a besoin d'espace libre pour faire son boulot, peu
importe que cet espace ait été "libéré" par le TRIM ou qu'il vienne
d'un pool réservé.

En fait le garbage collector n'a pas forcément besoin de beaucoup
d'espace libre pour travailler, puisque son rôle consiste précisément à
libérer des blocs pour qu'ils puissent être effacés et réutilisés pour
de futures écritures.
Par exemple s'il traite 10 blocs contenant 60 % de données valides (et
40 % de données périmées, soit parce qu'elles ont été modifiées et
réécrites ailleurs, soit parce qu'elles ont été marquées par TRIM), il a
besoin de 6 blocs vides pour y transférer les données valides, et
ensuite les 10 blocs d'origine peuvent être libérés et effacés.
C'est surtout l'écriture qui a besoin de blocs vides, afin de ne pas
attendre que des blocs soient effacés (ce qui est très long) pour
pouvoir y écrire à nouveau.
Je vais essayer avec l'utilitaire Samsung pour ce SSD (j'ai déjà tenté
de l'utiliser pour flasher le firmware du SSD avec une version qui amène
le TRIM, mais sans succès. A voir pour l'effacement).

Bah, c'était la mauvaise idée du jour... L'effacement s'est passé
normalement (du moins l'utilitaire n'a pas rapporté de problème), mais le
PC (un Thinkpad X301 je rappelle) est "à moitié brické" après ça :-(
Quand je l'allume il ne se passe rien (même à l'écran) pendant 10mn (!),
puis un message d'erreur est brièvement affiché (pendant 2s, je l'ai
veillé pour le photographier) :
"tpm tpm0: A TPM error(2B) occured continue selftest"
"tpm tpm0: TPM self test failed""
Après ça il boote s'il trouve un support externe bootable, sinon il dit
qu'il ne trouve aucun OS (donc le SSD a bien subi un effacement). En
bootant sur une clef d'installation de xubuntu, je ne vois pas du tout le
SSD (il n'est même pas proposé pour l'installation).
A aucun moment je n'ai l'opportunité d'entrer dans le BIOS. Si j'enlève
le SSD du PC le comportement est exactement le même.

Sur de très anciens ThinkPad (IBM, pas encore Lenovo) que j'ai eus, le
disque contenait une zone "cachée" (avec HPA, Host Protected Area)
réservée pour le BIOS. Peut-être que l"utilitaire a désactivé HPA et
effacé cette zone. Mais je n'ai pas constaté de dysfonctionnement après
avoir supprimé cette zone ou remplacé le disque par un autre disque
n'ayant pas cette zone.
pehache
Le #26506923
Le 24/01/2019 à 21:06, Pascal Hambourg a écrit :
Le 24/01/2019 à 19:16, pehache a écrit :
Le 23/01/2019 à 08:34, pehache a écrit :
Et il n'a pas
forcément besoin de TRIM ni de savoir lire le système de fichiers pour
fonctionner, s'il dispose de suffisamment de blocs supplémentaires qui
ne sont pas comptés dans la capacité visible.

Moui... j'avoue que ce n'est pas hyper clair pour moi, même si je crois
voir comment...

Oui en fait c'est assez évident, je ne sais pas pourquoi je "bloquais"
là-dessus. Le GC a besoin d'espace libre pour faire son boulot, peu
importe que cet espace ait été "libéré" par le TRIM ou qu'il vienne
d'un pool réservé.

En fait le garbage collector n'a pas forcément besoin de beaucoup
d'espace libre pour travailler, puisque son rôle consiste précisément à
libérer des blocs pour qu'ils puissent être effacés et réutilisés pour
de futures écritures.
Par exemple s'il traite 10 blocs contenant 60 % de données valides (et
40 % de données périmées, soit parce qu'elles ont été modifiées et
réécrites ailleurs, soit parce qu'elles ont été marquées par TRIM), il a
besoin de 6 blocs vides pour y transférer les données valides, et
ensuite les 10 blocs d'origine peuvent être libérés et effacés.
C'est surtout l'écriture qui a besoin de blocs vides, afin de ne pas
attendre que des blocs soient effacés (ce qui est très long) pour
pouvoir y écrire à nouveau.

Oui. Il me semble néanmoins que plus le GC dispose de blocs vides, plus
il peut retarder l'opération, avec à la clef une réduction du nombre
d'écriture.
Bah, c'était la mauvaise idée du jour... L'effacement s'est passé
normalement (du moins l'utilitaire n'a pas rapporté de problème), mais le
PC (un Thinkpad X301 je rappelle) est "à moitié brické" après ça :-(
Quand je l'allume il ne se passe rien (même à l'écran) pendant 10mn (!),
puis un message d'erreur est brièvement affiché (pendant 2s, je l'ai
veillé pour le photographier) :
"tpm tpm0: A TPM error(2B) occured continue selftest"
"tpm tpm0: TPM self test failed""
Après ça il boote s'il trouve un support externe bootable, sinon il dit
qu'il ne trouve aucun OS (donc le SSD a bien subi un effacement). En
bootant sur une clef d'installation de xubuntu, je ne vois pas du tout le
SSD (il n'est même pas proposé pour l'installation).
A aucun moment je n'ai l'opportunité d'entrer dans le BIOS. Si j'enlève
le SSD du PC le comportement est exactement le même.

Sur de très anciens ThinkPad (IBM, pas encore Lenovo) que j'ai eus, le
disque contenait une zone "cachée" (avec HPA, Host Protected Area)
réservée pour le BIOS. Peut-être que l"utilitaire a désactivé HPA et
effacé cette zone. Mais je n'ai pas constaté de dysfonctionnement après
avoir supprimé cette zone ou remplacé le disque par un autre disque
n'ayant pas cette zone.

Oui, j'ai imaginé un scénario dans le genre, avec l'espoir qu'en
installant un nouveau disque ça va décoincer le PC. Il se peut que le
Thinkpad tente d'accéder à une zone du genre dont tu parles, ou de
l'écrire s'il ne la trouve pas. Mais si j'ai briqué le SSD avec ma manip
(*) il n'y arrive pas.
Vu qu'il s'agit d'un SSD 1,8" et que c'est quasi-introuvable aujourd'hui
(on se demande bien pourquoi), j'ai commandé un mSata avec adaptateur
(j'ai vérifié, ça passe). En croisant les doigts...
(*) j'ai lu que le firmware de ces SSD Samsung était modifié par Lenovo,
et que pour les flasher avec l'utilitaire Samsung il y avait une ruse à
appliquer (qui ne marche pas sur le X301 au final), sinon il y avait un
risque de bricker le SSD. J'ai supposé que l'effacement ne présentait
par contre pas de risque, peut-être à tort !
--
"...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 #26506930
Le 24/01/2019 à 22:31, pehache a écrit :
Le 24/01/2019 à 21:06, Pascal Hambourg a écrit :
Le 24/01/2019 à 19:16, pehache a écrit :
Le GC a besoin d'espace libre pour faire son boulot, peu
importe que cet espace ait été "libéré" par le TRIM ou qu'il vienne
d'un pool réservé.



(...)
C'est surtout l'écriture qui a besoin de blocs vides, afin de ne pas
attendre que des blocs soient effacés (ce qui est très long) pour
pouvoir y écrire à nouveau.

Oui. Il me semble néanmoins que plus le GC dispose de blocs vides, plus
il peut retarder l'opération, avec à la clef une réduction du nombre
d'écriture.

Je suppose. Mais le garbage collector n'a pas besoin d'espace libre pour
travailler, c'est plutôt l'inverse : plus il y a d'espace libre, moins
il a besoin de travailler.
pehache
Le #26507233
Le 24/01/2019 à 22:31, pehache a écrit :
Bah, c'était la mauvaise idée du jour... L'effacement s'est passé
normalement (du moins l'utilitaire n'a pas rapporté de problème),
mais le
PC (un Thinkpad X301 je rappelle) est "à moitié brické" après ça :-(
Quand je l'allume il ne se passe rien (même à l'écran) pendant 10mn (!),
puis un message d'erreur est brièvement affiché (pendant 2s, je l'ai
veillé pour le photographier) :
"tpm tpm0: A TPM error(2B) occured continue selftest"
"tpm tpm0: TPM self test failed""
Après ça il boote s'il trouve un support externe bootable, sinon il dit
qu'il ne trouve aucun OS (donc le SSD a bien subi un effacement). En
bootant sur une clef d'installation de xubuntu, je ne vois pas du
tout le
SSD (il n'est même pas proposé pour l'installation).
A aucun moment je n'ai l'opportunité d'entrer dans le BIOS. Si j'enlève
le SSD du PC le comportement est exactement le même.

Sur de très anciens ThinkPad (IBM, pas encore Lenovo) que j'ai eus, le
disque contenait une zone "cachée" (avec HPA, Host Protected Area)
réservée pour le BIOS. Peut-être que l"utilitaire a désactivé HPA et
effacé cette zone. Mais je n'ai pas constaté de dysfonctionnement
après avoir supprimé cette zone ou remplacé le disque par un autre
disque n'ayant pas cette zone.

Oui, j'ai imaginé un scénario dans le genre, avec l'espoir qu'en
installant un nouveau disque ça va décoincer le PC. Il se peut que le
Thinkpad tente d'accéder à une zone du genre dont tu parles, ou de
l'écrire s'il ne la trouve pas. Mais si j'ai briqué le SSD avec ma manip
(*) il n'y arrive pas.
Vu qu'il s'agit d'un SSD 1,8" et que c'est quasi-introuvable aujourd'hui
(on se demande bien pourquoi), j'ai commandé un mSata avec adaptateur
(j'ai vérifié, ça passe). En croisant les doigts...

Le nouveau SSD n'a rien résolu, mais j'ai retrouvé un fonctionnement
normal du X301 en flashant le BIOS avec une ancienne version... Ouf !
http://prntscr.com/mcney1
En haut : le SSD Samsung 1,8" d'origine
En bas : le SSD Kingston mSATA sur l'adaptateur 1,8". J'ai découpé et
fixé un bout de carton rigide au gabarit 1,8" pour que le nouveau SSD ne
bouge pas dans le logement, et accroché une ficelle pour pouvoir le
sortir facilement.
--
"...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
Doug713705
Le #26507238
Le 2019-01-26, pehache nous expliquait dans
fr.comp.stockage
(
Le nouveau SSD n'a rien résolu, mais j'ai retrouvé un fonctionnement
normal du X301 en flashant le BIOS avec une ancienne version... Ouf !
http://prntscr.com/mcney1
En haut : le SSD Samsung 1,8" d'origine
En bas : le SSD Kingston mSATA sur l'adaptateur 1,8". J'ai découpé et
fixé un bout de carton rigide au gabarit 1,8" pour que le nouveau SSD ne
bouge pas dans le logement, et accroché une ficelle pour pouvoir le
sortir facilement.

Et l'ensemble apatateur + mSATA ne rentrerait pas dans le boitier du
Samsung ?
Quitte à ce qu'il soit mort, autant se servir du cadavre ;-)
--
Je sais que dans votre alchimie
L'atome ça vaut des travellers-chèques
Et ça suffit comme alibi
-- H.F. Thiéfaine, Aligator 427
pehache
Le #26507242
Le 27/01/2019 à 07:45, Doug713705 a écrit :
Le 2019-01-26, pehache nous expliquait dans
fr.comp.stockage
(
Le nouveau SSD n'a rien résolu, mais j'ai retrouvé un fonctionnement
normal du X301 en flashant le BIOS avec une ancienne version... Ouf !
http://prntscr.com/mcney1
En haut : le SSD Samsung 1,8" d'origine
En bas : le SSD Kingston mSATA sur l'adaptateur 1,8". J'ai découpé et
fixé un bout de carton rigide au gabarit 1,8" pour que le nouveau SSD ne
bouge pas dans le logement, et accroché une ficelle pour pouvoir le
sortir facilement.

Et l'ensemble apatateur + mSATA ne rentrerait pas dans le boitier du
Samsung ?

Ah oui, je n'y ai pas pensé. Mais je ne pense pas que ça rentre : la
partie en plastique du connecteur est plus longue vers l'arrière et
l'encoche du boîtier ne va pas suffire. Et même en épaisseur à mon avis
ça ne passe pas (le SSD mSATA est décollé de la surface de l'adaptateur
et l'épaisseur du tout n'est pas négligeable).
Quitte à ce qu'il soit mort, autant se servir du cadavre ;-)


Oui. Après je n'ai pas la certitude qu'il soit irrécupérable, et je
n'aime pas jeter ! Je ferai sûrement une nouvelle tentative plus tard,
j'ai vu par exemple qu'on pouvait activer une fonction cachée dans le
BIOS du X301 pour effacer proprement les SSD.
J'ai fait assez de conneries jusqu'à maintenant et comme tout marche je
vais me tenir un peu à carreau :-), mais je reviendrai sûrement dessus
quand même.
--
"...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 #26511330
Le 27/01/2019 à 09:45, pehache a écrit :
Le 27/01/2019 à 07:45, Doug713705 a écrit :
Le 2019-01-26, pehache nous expliquait dans
fr.comp.stockage
(
Le nouveau SSD n'a rien résolu, mais j'ai retrouvé un fonctionnement
normal du X301 en flashant le BIOS avec une ancienne version... Ouf !
http://prntscr.com/mcney1
En haut : le SSD Samsung 1,8" d'origine
En bas : le SSD Kingston mSATA sur l'adaptateur 1,8". J'ai découpé et
fixé un bout de carton rigide au gabarit 1,8" pour que le nouveau SSD ne
bouge pas dans le logement, et accroché une ficelle pour pouvoir le
sortir facilement.

Et l'ensemble apatateur + mSATA ne rentrerait pas dans le boitier du
Samsung ?

Ah oui, je n'y ai pas pensé. Mais je ne pense pas que ça rentre : la
partie en plastique du connecteur est plus longue vers l'arrière et
l'encoche du boîtier ne va pas suffire. Et même en épaisseur à mon avis
ça ne passe pas (le SSD mSATA est décollé de la surface de l'adaptateur
et l'épaisseur du tout n'est pas négligeable).
Quitte à ce qu'il soit mort, autant se servir du cadavre ;-)

Oui. Après je n'ai pas la certitude qu'il soit irrécupérable, et je
n'aime pas jeter ! Je ferai sûrement une nouvelle tentative plus tard,
j'ai vu par exemple qu'on pouvait activer une fonction cachée dans le
BIOS du X301 pour effacer proprement les SSD.
J'ai fait assez de conneries jusqu'à maintenant et comme tout marche je
vais me tenir un peu à carreau :-), mais je reviendrai sûrement dessus
quand même.

J'y suis revenu, et j'ai réussi à effacer proprement le SSD d'origine
depuis la fonction prévue pour dans le BIOS. J'aurais dû commencer par
là... (mais c'était une fonction cachée qu'il a fallu activer en
reflashant le BIOS avec un utilitaire spécial). Je n'ai pas essayé de
l'utiliser mais il est à nouveau visible depuis l'installateur de
Xubuntu, ce qui est déjà bon signe.
--
"...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
Poster une réponse
Anonyme