Restaurer les performances et estimer la durée de vie d'un disque SSD usagé ?

Sous Linux, il suffit d'exécuter

hdparm --trim-sector-ranges start:count /dev/sda

en passant les plages de blocs que vous voulez TRIM au lieu de start y count et le dispositif SSD à la place de /dev/sda . Il a l'avantage d'être rapide et de ne pas écrire de zéros sur le disque. Elle envoie simplement des commandes TRIM au contrôleur du SSD pour lui faire savoir que vous ne vous souciez pas des données contenues dans ces blocs et qu'il peut librement les considérer comme inutilisées dans son algorithme de collecte des déchets.

Vous devez probablement exécuter cette commande en tant que root. Puisque cette commande est extrêmement dangereuse, car elle peut immédiatement causer une perte de données majeure, vous devez également passer --please-destroy-my-drive argument pour hdparm (Je ne l'ai pas ajouté à la ligne de commande pour éviter la perte accidentelle de données causée par le copier-coller).

Dans la ligne de commande ci-dessus, /dev/sda doit être remplacé par le périphérique SSD auquel vous souhaitez envoyer des commandes TRIM. start est l'adresse du premier bloc (secteur) à TRIM, et count est le nombre de blocs à marquer comme libres à partir de cette adresse de départ. Vous pouvez passer plusieurs plages à la commande.

Après l'avoir fait personnellement avec hdparm v9.32 sur Ubuntu 11.04 sur mon ordinateur portable avec un Crucial RealSSD C300 de 128 Go, je dois signaler un problème : Je n'ai pas été en mesure de passer le nombre total de blocs de disque (0:250069680) comme plage. J'ai trouvé manuellement (essentiellement "recherche binaire" à la main) une valeur suffisamment grande pour le nombre de blocs qui fonctionnait (40000) et j'ai pu lancer des commandes TRIM sur une séquence de 40000 plages pour libérer l'ensemble du disque. Il est possible de le faire avec un simple Shell Shell comme ceci (testé sur Ubuntu 11.04 sous root) :

 # fdisk -lu /dev/sda

 Disk /dev/sda: 128.0 GB, 128035676160 bytes
 255 heads, 63 sectors/track, 15566 cylinders, total 250069680 sectors
 ...  

pour effacer l'ensemble du disque, prenez ce nombre total de secteurs et remplacez 250069680 dans la ligne suivante par ce nombre et exécutez (ajouter --please-destroy-my-drive ) :

 # i=0; while [ $i -lt 250069680 ]; do echo $i:40000; i=$(((i+40000))); done \
 | hdparm --trim-sector-ranges-stdin /dev/sda

Et c'est fini ! Vous pouvez essayer de lire le contenu brut du disque avec hexedit /dev/sda avant et après et vérifiez que le lecteur a éliminé les données.

Bien sûr, même si vous ne souhaitez pas utiliser Linux comme système d'exploitation principal de la machine, vous pouvez tirer parti de cette astuce en démarrant à partir d'un CD live et en l'exécutant sur le lecteur.

Tout d'abord, commençons par comprendre ce qui est à l'origine de la dégradation des performances. Sans cela, beaucoup de gens proposeront des solutions inadéquates (comme je le vois déjà). Le nœud du problème réside dans le fait suivant, cité dans le document suivant Wikipedia . Souviens-toi de ça, c'est important :

Avec la mémoire flash NAND, les opérations de lecture et de programmation doivent être effectuées page par page, tandis que le déverrouillage et l'effacement doivent se faire par bloc.

Les SSD sont constitués de flash NAND, et la flash est constituée de "blocs". Chaque bloc contient de nombreuses "pages". Pour simplifier, imaginons que nous venons d'acheter un nouveau SSD qui contient un seul bloc de mémoire, et que ce bloc est composé de 4 pages vides.

Pour plus de clarté, je fais la différence entre les pages vides, les pages utilisées et les pages supprimées avec , 1 et X. La clé étant que il y a une différence entre chacun d'eux du point de vue des contrôleurs ! Ce n'est pas aussi simple que des 1 et des 0. Donc, pour commencer, les pages de notre disque frais ressemblent à ceci :

, , , , (tous vides)

Maintenant, nous allons écrire des données sur le disque, et elles finissent par être stockées dans cette première page, donc :

1, , ,

Ensuite, nous écrivons un peu plus de données, mais cette fois-ci suffisamment pour qu'elles nécessitent deux pages, et elles sont donc stockées dans les deuxième et troisième pages :

1, 1, 1,

Nous manquons d'espace ! Nous décidons que nous n'avons pas vraiment besoin des données initiales que nous avons écrites, alors supprimons-les pour faire de la place.. :

X, 1, 1,

Enfin, nous devons stocker un autre ensemble important de données, qui occupera les deux pages restantes. C'EST LÀ QUE SE PRODUIT LA BAISSE DE PERFORMANCE DANS LES ENTRAÎNEMENTS SANS GARNITURE !!! Passer de notre dernier état à celui-ci :

1, 1, 1, 1

...nécessite plus de travail que la plupart des gens ne le pensent. Encore une fois, cela est dû au fait que la flash ne peut effacer que par blocs, et non par pages, ce qui est précisément ce que demande la transition finale ci-dessus. La différence entre les SSD basés sur TRIM et ceux basés sur non-TRIM est la suivante quand les travaux suivants sont effectués !

Puisque nous devons utiliser une page vide et une page supprimée, le SSD doit d'abord lire le contenu de l'ensemble du bloc dans une mémoire externe, effacer le bloc original, modifier le contenu, puis réécrire ce contenu dans le bloc. . Ce n'est pas aussi simple qu'une "écriture", c'est devenu une "lecture-erreur-écriture". C'est un changement important, et le fait qu'il se produise alors que nous écrivons beaucoup de données est probablement le moment le plus inopportun pour qu'il se produise. Tout cela pourrait être évité si cette page "effacée" était récupérée à l'avance, ce qui est précisément le but de TRIM. Avec TRIM, le SSD récupère nos pages supprimées immédiatement après la suppression ou à un autre moment opportun que ses algorithmes TRIM jugent approprié. L'important, c'est qu'avec TRIM, cela ne se produit pas au milieu d'une écriture !

Sans TRIM, nous ne pouvons finalement pas éviter le scénario ci-dessus lorsque nous remplissons nos disques de données. Heureusement, certains SSD plus récents vont au-delà de TRIM et font effectivement la même chose que TRIM en arrière-plan au niveau matériel sans les commandes ATA nécessaires (certains appellent cela garbage collection). Mais pour ceux d'entre nous qui n'ont pas la chance de posséder l'un ou l'autre, il est important de savoir que L'écriture de zéros sur tout le disque n'est pas suffisante pour récupérer les performances d'origine !!!!!. L'écriture de tous les zéros sur le lecteur n'indique pas au contrôleur que la page de la mémoire flash est libre pour l'écriture. La seule façon de le faire sur un lecteur qui ne prend pas en charge TRIM est d'invoquer la commande d'effacement sécurisé ATA sur votre lecteur en utilisant un outil tel que HDDErase (via Wayback Machine) .

I croire Certains des premiers disques SSD ne prenaient en charge TRIM qu'en cas de suppression de partitions ou de commandes telles que "diskpart clean all" de Windows 7, et non en cas de suppression de fichiers individuels. C'est peut-être la raison pour laquelle un disque plus ancien semblait retrouver ses performances après l'exécution de cette commande. Cela semble un peu flou pour moi cependant ...

Une grande partie de mes connaissances sur les SSD et le matériel/les gadgets en général provient de anandtech.com . Je pensais qu'il avait un excellent article expliquant tout cela, mais je n'arrive pas à le trouver !

Apparemment, la recommandation standard est de faire une écriture complète de tous les zéros sur le disque dur. Je ne suis pas entièrement Je ne suis pas sûr que cela soit utile (un grand nombre d'écritures ne finit-il pas par tuer les SSD ?), mais cela semble être approuvé par les forums de support SSD des principaux fournisseurs.

Donc, pour faire ça dans Windows :

• lancer une invite de commande avec des privilèges d'administrateur
• exécuter la commande diskpart

Une fois dans l'utilitaire, vous verrez un DISKPART> et tapez les commandes suivantes :

DISKPART> list disk
DISKPART> select disk x

Évidemment, VÉRIFIEZ QUE VOUS AVEZ SÉLECTIONNÉ LE BON LECTEUR SSD avant de poursuivre !

DISKPART> clean all
DISKPART> create partition primary
DISKPART> format quick fs=NTFS 

La magie ici est clean all dont écrit tous les zéros dans le lecteur :

Si vous spécifiez le paramètre all, chaque secteur peut être mis à zéro, et toutes les données contenues sur le disque peuvent être effacées.

Après avoir fait cela, je peux confirmer que les performances du disque ont considérablement augmenté.

J'ai aussi trouvé un outil, SSD Life Pro . Il a de mauvaises nouvelles pour moi.

Quant à la façon dont il calcule cela, il utilise les indicateurs SMART SSD. Apparemment, il essaye de prédire en se basant sur les données S.M.A.R.T. :

• La durée de vie de la mémoire flash, sur laquelle sont basés les SSD, est limitée à 10 000 écritures par cellule.
• La plupart des lecteurs affichent également des données sur les informations écrites et/ou lues dans leurs paramètres S.M.A.R.T.

C'est délicat car il doit aussi savoir quand les données ont été écrites pour être estimées, mais voici les données sous-jacentes :

01 Read Error Rate   7
09 Power-on Hours Count  7085
0C Power Cycle Count   318
B8 Initial Bad Block Count   15
C3 Program Failure Block Count   0
C4 Erase Failure Block Count   0
C5 Read Failure Block Count  0
C6 Read Sectors   5468243171
C7 Write Sectors  41640920876
C8 Read Commands  100482453
C9 Write Commands   417315851
CA Error Bits from Flash  345270
CB Read Sectors with Correctable Bit Error  340001
CC Bad Block Full Flag   0
CD Maximum P/E Count Specification   5000
CE Minimum Erase Count   3774
CF Maximum Erase Count   65348
D0 Average Erase Count   4837
D1 Remaining Drive Life  4

Le chiffre effrayant ici est Durée de vie restante du disque qui est de 4.. pour cent !

Et les calculs qui en résultent :

Model: CRUCIAL\_CT128M225
Size: 128 GB
Serial number: xxxxxxxxxxxxxxxxx456
Firmware: 2030
Powered on times: 318    
TRIM support in drive/OS: enabled/enabled
Worked time: 9 months 16 days 5 hours
Total data read: 2607.46 GB
written: 19855.94 GB

Pour mémoire, ce disque a été acheté en octobre 2009, il a donc un peu plus d'un an et demi.

J'ai découvert qu'écrire des zéros dans le lecteur n'est pas la meilleure approche. Bien que cela puisse aider à court terme, j'ai constaté que cela n'a certainement pas restauré mon disque à sa pleine performance (j'ai un assez vieux Intel-SSD non compatible TRIM). Après environ un an d'utilisation assez intensive, j'ai commencé à rencontrer des blocages d'une à deux secondes lorsque le SSD tentait d'écrire sur le disque dur. tout même après avoir remis à zéro le SSD.

La seule chose que j'ai trouvée qui rétablit complètement les performances était une effacement sécurisé en utilisant hdparm . J'ai pris l'habitude d'effacer mon SSD tous les 6 à 12 mois lorsqu'il commence à avoir des problèmes mineurs. Quelqu'un sur Macrumors a fait une recherche spécifique à mac. tutoriel sur la façon de faire pour les appareils mac*.

D'après toutes les déclarations que j'ai vues, un effacement sécurisé envoie une commande spéciale au SSD qui lui fait remettre tous les secteurs à zéro à un niveau bien inférieur à celui de l'utilisation de l'effacement normal. dd ou quelque chose comme ça.