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.
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.
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.
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 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
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
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 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...
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.
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 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.
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.
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 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
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
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 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.
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.
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 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
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
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 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
Le 2019-01-26, pehache nous expliquait dans
fr.comp.stockage
(<gb4a3eFhdu9U1@mid.individual.net>) :
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
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 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
Le 27/01/2019 à 07:45, Doug713705 a écrit :
Le 2019-01-26, pehache nous expliquait dans
fr.comp.stockage
(<gb4a3eFhdu9U1@mid.individual.net>) :
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
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 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
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
(<gb4a3eFhdu9U1@mid.individual.net>) :
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
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
