Longévité des disques SSD

Bonjour Yankee 71100

Peut être que ce message sera compris par certains, quant à moi je n'ai pas les compétences nécessaires pour comprendre tout ce charabia purement technique.

J'ai pu relever cependant dans la conclusion ce qui conforte mon opinion déjà annoncée concernant l'avenir des SSD, c'est à dire la promesse de nouvelles générations encore plus performantes et moins chères et dont la durée de vie sera plus longue.

Concernant le présent, nous souhaitons toujours avoir un avis d'experts (mais seulement un résumé qui peut être compris par tous), voire les témoignages d'un plus grand nombre d'utilisateurs avertis ayant longuement expérimenté des SSD, mais c'est dommage qu'on ne croise presque jamais cette catégorie de personnes dans ce forum.

Bonjour

après plusieurs tests fait voici un premier rapport de SSD

Secteurs, pages et blocs

Ces trois mots sont la principale cause des chutes de performances lors de petits accès aléatoires. Le secteur est l'unité d'adressage de base d'un disque dur. Il fait quasiment toujours 512 octets, et la norme ATA a donc repris cette taille de 512 octets comme l'unité de base pour les transferts. Avec les disques durs, c'est idéal, puisqu'on a alors un mapping 1:1 entres les secteurs logiques vus de l'extérieur et les secteurs physiques gérés par le contrôleur du disque. Ainsi, quand on envoie un secteur à écrire sur le disque, le contrôleur n'a pas à se poser des questions, il a simplement à écrire le secteur à l'endroit demandé, sans se préoccuper des données existantes, qui sont écrasées.

Mais sur un SSD, ce mapping 1:1 n'existe plus car le contrôleur n'utilise pas les mêmes unités d'adressage physique qu'un contrôleur de disque dur : adieu les secteurs, bonjour les pages et les blocs.

Les pages sont les unités de base pour la lecture et l'écriture. Leur taille est généralement comprise entre 1 Ko et 4 Ko (plus quelques octets pour stocker le code de contrôle et de correction d'erreurs). Il s'agit donc de la taille minimale qui peut être lue ou écrite lors d'une opération. L'interface SATA travaillant généralement avec des secteurs de 512 octets, on se rend vite compte que, si la taille "élevée" des pages n'est pas problématique en séquentiel (on va accéder à plusieurs secteurs consécutifs, donc au final, on va demander des pages complètes, et toutes les données accédées par le SSD seront utiles), elle le devient vite en aléatoire : si on accède à 512 octets à un endroit, puis 512 octets à un autre, puis encore 512 octets ailleurs, le contrôleur va à chaque fois devoir accéder à une page complète, alors que seule une partie des données est utile. Avec des pages de 4 Ko, le volume de données traitées par le contrôleur sera dans ce cas jusqu'à 8 fois supérieur à celui demandé par le système. Les performances pourront donc être divisées par 8 par rapport au mode séquentiel, sans compter l'influence des temps d'accès.

Le bloc est encore plus problématique : il s'agit de l'unité de base pour l'effacement des données. Sa taille est généralement comprise entre 128 Ko et 512 Ko. À chaque fois que le contrôleur doit écrire des données dans une page qui a déjà été écrite, tout le bloc contenant cette page doit être effacé, pour permettre la réécriture de la page concernée. Mais comme les autres pages du bloc peuvent contenir des données qui ne doivent pas être effacées, il va en fait falloir lire toutes les pages non vierges du bloc, effacer le bloc, puis réécrire toutes les pages non vierges. Sur un SSD dotés de pages de 2 Ko et de blocs de 512 Ko, la réécriture d'un secteur ATA de 512 octets va donc nécessiter la lecture de jusqu'à 512 Ko de données, puis l'effacement du même volume, et enfin l'écriture de ce même volume. Dans le pire des cas, on va donc avoir à traiter 1024 Ko de données (on néglige l'effacement), soit 20 fois plus que sur un disque dur qui se contenterait d'écraser un secteur de 512 octets. Pour le mapping entre les secteurs et les pages de la mémoire flash, la plupart des SSD affectent un groupe de secteurs consécutifs aux pages d'un même bloc. Cette solution a l'avantage d'être relativement simple, mais la réécriture d'un secteur appartenant à un bloc entièrement écrit va nécessiter la réécriture de tout le bloc. C'est pourquoi certains SSD haut de gamme commencent à réaliser un mapping plus fin, se faisant au niveau des pages, ce qui permet d'augmenter fortement les performances en écriture aléatoire, puisqu'il n'est plus nécessaire de déplacer tout un bloc pour réécrire simplement un secteur. C'est ainsi que fonctionnent par exemple les contrôleurs Sandforce SF-1200 et SF-1500.

On notera également qu'en plus de l'état programmé et de l'état vierge, les pages peuvent être dans un troisième état : l'état effaçable. Cet état signifie que la page contient des données, mais que ces données ne sont plus valides et donc qu'elles n'auront pas besoin d'être réécrites après effacement du bloc. Ainsi, si un bloc de 512 Ko contient 100 Ko de pages programmées, 200 Ko de pages vierges et 212 Ko de pages effaçables, le contrôleur du SSD sait que ce bloc pourra être utilisé pour écrire jusqu'à 412 Ko, car après effacement il ne contiendra que 100 Ko de pages programmées.

Wear-leveling

En plus de l'adressage radicalement différent, les SSD ont une autre particularité par rapport aux disques durs : les cellules s'usent au fil des cycles écriture/effacement, ce qui réduit progressivement la durée de rétention des données (durée pendant laquelle une donnée reste lisible). Chaque cellule est donc spécifiée pour un nombre maximal d'effacements tolérés. Selon les normes du JEDEC, ce nombre maximal doit être défini de telle sorte que la durée de rétention des données soit garantie à au moins dix ans pour une cellule ayant subit jusqu'à 10% du nombre de cycles maximal, et au minimum un an pour une cellule ayant atteint son nombre de cycles maximal. Sur les cellules MLC gravées en 50 nm, le nombre maximal d'effacements tolérés est d'environ 10 000, contre environ 100 000 pour les mémoires de type SLC. À noter que, si ce facteur 10 peut sembler énorme, il est quasiment sans conséquences en pratique pour un usage grand public, dans le cadre duquel les SSD auront généralement été remisés bien avant d'atteindre leurs limites, même en MLC. Par ailleurs, le nombre de cycles supportés décroît en fonction de la finesse de gravure. La MLC 34nm ne supporte par exemple plus que 5 000 cycles, et la MLC 25nm devrait tomber à 3 000.

Problème : nos systèmes d'exploitation ne sont pas adaptés à ce mode de fonctionnement, et vont donc parfois réécrire très souvent certains secteurs logiques, alors que d'autres ne sont jamais touchés. Les contrôleurs mémoire des SSD implémentent donc des algorithmes dits de "wear-leveling" ("nivellement d'usure"), qui vont répartir les écritures sur toute la "surface" du SSD, pour éviter que certaines cellules ne s'usent prématurément.

Contrairement à ce qu'il se passe avec un disque dur, un secteur logique donné ne sera donc pas toujours écrit au même endroit, et va se "promener" au grès des écritures.

Revers de la médaille, ce mode de fonctionnement a tendance à diminuer les performances en écriture, car à chaque écriture, le contrôleur doit parcourir les descripteurs lui permettant de savoir quelle page est la mieux adaptée pour accueillir les données. Cette chute de performances est particulièrement sensible sur les SSD à base de mémoire MLC et pour les petites opérations d'écriture aléatoire. Afin d'éviter une trop forte dégradation des performances, il est impératif que le SSD soit doté d'un cache conséquent, lui permettant de stocker les descripteurs, pour ne pas à devoir les relire depuis la mémoire flash à chaque opération. En l'absence de cache (cas des SSD à base de contrôleur Jmicron JMF602 par exemple), les performances dans ce cas tombent bien en dessous de celles des disques durs, avec des temps de réponse atteignant parfois plusieurs centaines de millisecondes.

Mais le wear-leveling a également une conséquence gênante : il provoque une "fragmentation" du volume, qui a tendance à s'accroître avec le temps, et à dégrader les performances en écriture. En effet, imaginons par exemple l'écriture d'un fichier de 1 Mo, sur un SSD doté de pages de 2 Ko et de blocs de 512 Ko. Sur un SSD neuf, toutes les cellules étant vierge, le fichier va être écrit en un seul morceau, sur deux blocs consécutifs. Plus tard, en cas de réécriture du fichier, le contrôleur va privilégier les pages encore vierges, puis, à défaut, les pages effaçables optimales (en privilégiant les pages appartenant à des blocs contenant beaucoup de pages effaçables ou vierges et ayant subit le moins d'effacement). Plus le SSD a été utilisé, moins il devient probable de trouver deux blocs entièrement utilisables (donc ne contenant que des pages vierges ou effaçables). Le fichier a donc toutes les chances d'être réparti sur plus de deux blocs. Au fil du temps, on finit donc par arriver à une situation où il ne reste aucun bloc entièrement utilisable pour des écritures, ce qui signifie que chaque nouvelle opération d'écriture va nécessiter l'effacement de blocs contenant des données, ce qui oblige à lire puis réécrire ces données (cf fin du paragraphe "Secteurs, pages, blocs...").

Lorsque la réécriture d'un secteur ne se fait pas physiquement au même endroit que l'écriture précédente, le contrôleur du SSD marque comme effaçable la page qui contenait le secteur avant sa réécriture.

Enfin, en plus du wear-leveling, le contrôleur doit s'assurer d'éviter le vieillissement des données. Comme nous l'avons expliqué plus haut, les données ont une durée de vie limitée après leur écriture. Lors des phases de faible activité, le contrôleur va donc vérifier l'âge des données sur le volume, et réécrire celles qui s'approchent de l'âge limite (avec généralement une marge conséquente par rapport à la durée de rétention garantie par les normes du JEDEC, pour éviter les pertes de données).

Trim

Comme un même secteur logique n'est pas toujours écrit dans la même page, il est important que le contrôleur du SSD dispose en permanence d'une information la plus fiable possible sur la validité des données qu'il contient. En effet, lorsqu'on efface un fichier, la plupart des systèmes d'exploitation se contentent actuellement de supprimer son entrée dans les descripteurs du système de fichiers, mais ne l'effacent pas physiquement, car c'est inutile sur un disque dur (une écriture future au même emplacement pouvant se faire sans effacement préalable). Sur un SSD ce mode de fonctionnement peut engendrer des écritures inutiles. Imaginons par exemple qu'un bloc de 512 Ko contienne 256 Ko appartenant à un fichier, et 256 Ko de pages effaçables. Si on efface le fichier, puis on écrit un nouveau fichier de 128 Ko et si ce bloc est le bloc choisi pour effectuer l'écriture, le contrôleur va lire les 256 Ko correspondant au fichier supprimé, puis effacer le bloc, réécrire les 256 Ko du fichier supprimé, puis les 128 Ko du nouveau fichier. On va donc écrire trois fois plus de données que nécessaire, ce qui ralenti l'écriture du nouveau fichier. De plus, on se retrouve alors avec un bloc contenant 128 Ko de pages vierges, alors qu'il pourrait en contenir 384 Ko, ce qui va ralentir certaines écritures futures.

La solution à ce problème est la commande TRIM ("rogner" en anglais), une nouvelle commande qui vient d'être introduite dans le protocole ATA. Lors de l'effacement d'un fichier, les systèmes d'exploitation supportant cette commande vont l'envoyer au SSD pour lui indiquer la liste des secteurs logiques correspondant au fichier supprimé, et le contrôleur marquera alors les pages concernées comme étant effaçables. Si on reprend l'exemple ci-dessus, au moment de l'écriture du nouveau fichier de 128 Ko, le contrôleur va voir un bloc contenant non plus 256 Ko de données et 256 Ko effaçables, mais 512 Ko effaçables, et il va donc effacer le bloc sans lecture préalable, et en n'écrivant ensuite que les 128 Ko du nouveau fichier.

La commande TRIM est pour l'instant supportée par Windows 7 et les noyaux Linux récents. Côté SSD, elle est supportée sur les principaux contrôleurs du marché (Indilinx Barefoot, Samsung PB22-J, Intel G2...), mais pas toujours avec les firmwares d'origine. Intel et Indilinx fournissent également des utilitaires permettant d'envoyer de temps en temps une commande TRIM sur les systèmes Windows XP et Vista. Une solution moins efficace, puisque le TRIM n'est pas envoyé à chaque effacement, mais c'est mieux que rien.

La commande TRIM pose également quelques problèmes dans le cas d'un montage en RAID : pour qu'elle soit utilisable, il faut que le contrôleur RAID soit capable de la gérer, ce qui est loin d'être le cas général.

Si vous utilisez un SSD et un système d'exploitation supportant le TRIM, il faudra également être particulièrement attentif à la sauvegarde de vos données : en cas d'effacement accidentel de fichiers, le fait d'avoir envoyé la commande TRIM les rend définitivement irrécupérables.

Garbage collector

Le garbage collector est une fonction présente sur certains contrôleurs (Samsung PB22-J, Indilinx Barefoot, Intel, et probablement d'autres). Il s'agit d'un algorithme permettant d'optimiser les performances en écriture en profitant des périodes de faible activité du système, sur un principe similaire à celui du garbage collector qu'on retrouve dans certains langages de programmation.

Pendant les périodes d'inactivité, le SSD réorganise les données de façon à optimiser les écritures futures. Comme nous l'avons vu plus haut, les SSD sont plus performants en écriture séquentielle qu'en écriture aléatoire. Pour optimiser les performances, il faut donc faire en sorte qu'un maximum d'opérations se fasse de manière séquentielle. Ceci peut être fait en profitant de l'état effaçable des pages : lorsque l'activité est faible, le contrôleur va déplacer les données sur le SSD, pour remplacer les pages effaçables des blocs contenant des pages programmées par des pages programmées issues d'autres blocs, augmentant ainsi le nombre de blocs ne contenant que des pages vierges. Ce procédé est en fait relativement proche de ce que fait un logiciel de défragmentation, mais ce fait au niveau physique, niveau auquel aucun logiciel ne peut intervenir sur un SSD, la structure physique n'étant pas exposée au logiciel (contrairement au disque dur, dont la structure physique est identique à la structure logique).

Le garbage collector permet de limiter les pertes de performances dans le temps, même sans utiliser le TRIM, tandis que l'association du TRIM et du garbage collector permet d'obtenir des gains importants, le TRIM permettant au garbage collector d'avoir à sa disposition bien plus de pages effaçables.

Les contrôleurs : les forces en présence

Alors que les disques durs nécessitaient un savoir faire pointu et des chaînes de fabrication spécialisées, fabriquer un SSD est à la portée de n'importe quel fabricant de produits électronique : comme n'importe quel carte électronique, un SSD n'est rien de plus qu'un assemblage de composants sur un circuit imprimé.

Ainsi, alors que le marché des disques durs était monopolisé par une poignée de constructeurs concevant et produisant leurs disques, le marché du SSD a très vite été envahi par un grand nombre de constructeurs, dont une bonne part fabriquaient déjà d'autres produits à base de mémoire flash ou RAM : OCZ, Corsair, A-Data, Patriot, SuperTalent, Sandisk, Samsung, Transcend, Intel, Crucial, G.skill, Kingston, MemoRight, Mtron, Toshiba, Chaintech, CSX, Western Digital, Seagate...

Au début, les fabricants historiques de disques durs étaient rares sur le marché des SSD, puisque seuls Samsung et Toshiba y étaient présents quasiment dès le début (et pour cause, ils sont tous deux également des gros producteurs de mémoire flash). Western Digital a présenté il y a peu ses premiers produits SSD, issus du rachat d'une entreprise spécialisée (SiliconSystems), Seagate devrait se lancer très rapidement avec des produits haut de gamme à base de mémoire SLC tandis qu'Hitachi va collaborer avec Intel, mais n'a pour l'instant présenté aucun produit.

En plus des constructeurs de disques durs et des fabriquants de mémoire flash, on trouve également deux autres types de constructeurs de SSD : ceux qui conçoivent et fabriquent leurs SSD et ceux qui se contentent de fabriquer des SSD basés sur des contrôleurs conçus par des tiers (notez que certains fabricants de mémoire flash ont également opté pour des contrôleurs tiers, plutôt que d'en développer un eux même). C'est ainsi que le point clé dans le choix d'un SSD n'est finalement pas son constructeur, mais plutôt le constructeur de son contrôleur, tout comme le constructeur d'un GPU est un critère plus important que le constructeur de la carte dans le choix d'une carte graphique.

Sur le marché grand public, ce sont essentiellement quatre constructeurs de contrôleurs qui se partagent le marché, tandis qu'un cinquième très prometteur arrivera en 2010 :

• Jmicron : Jmicron a beaucoup fait couler d'encre avec son contrôleur JMF602. Très répandu sur les SSD d'entrée de gamme, ce contrôleur est en effet devenu tristement célèbre à cause de ses piètres performances en accès aléatoires, dues à l'absence de mémoire cache. Certains SSD utilisent deux contrôleurs JMF602 montés en RAID via un contrôleur JMB390, mais cette solution améliore surtout les performances séquentielles et induit une consommation élevée pour un SSD. Son successeur, le JMF612 est arrivé fin 2009. Contrairement au JMF602, il gère un cache pouvant aller jusqu'à 256 Mo et supporte le TRIM, ce qui lui confère des performances nettement supérieures, sans pour autant atteindre celles des ténors du marché.
• Samsung : fabricant de disques durs et de mémoire flash, Samsung avait tout intérêt à se lancer sur le marché des SSD. Arrivé assez tôt avec une première génération doté de performances correctes (PM410/PS410), le constructeur a lancé début 2009 son nouveau contrôleur PB22-J, qui fait partie des meilleurs et supporte le TRIM depuis fin 2009, via une mise à jour du firmware.
• Intel : le géant des processeur n'a pas non plus raté le coche des SSD. Son contrôleur, passé en version 2 il y a peu, est considéré par beaucoup comme le meilleur du marché, son seul gros défaut étant une vitesse relativement faible en écriture séquentielle sur les mémoires MLC. Il survole par contre la concurrence en aléatoire. En version 2 (dite Postville), il supporte le TRIM avec les versions récentes du firmware.
• Indilinx : la bonne surprise de 2009 ! Le contrôleur Barefoot d'Indilinx est actuellement l'un des meilleurs compromis, avec des performances élevées en séquentiel, aussi bien en lecture qu'en écriture, et une bonne résistance en aléatoire. C'est le contrôleur utilisé par les Vertex d'OCZ, un modèle de SSD particulièrement populaire. Ses performances ont par contre tendance à se dégrader dans le temps, mais ce défaut s'estompe au fil des révisions du firmware, et n'est quasiment plus qu'un souvenir avec les OS supportants le TRIM. Il devait être remplacé en 2010 par le Jet Stream, qui exploitera le SATA 6 Gbits/s pour atteindre des débits de l'ordre de 500 Mo/s, le double de ceux du Barefoot, mais ce nouveau contrôleur a été reporté à 2011. En attendant, Indilinx propose le ECO, une révision du Barefoot compatible avec la mémoire flash 34nm, moins coûteuse.
• Sandforce : c'est le petit nouveau sur le marché. Deux contrôleurs ont pour l'instant été annoncés, le SF-1500 pour le marché entreprise et le SF-1200 pour le marché grand public. Sur le papier, ces nouveaux contrôleurs pourraient devenir la nouvelle référence de performances. Mais il faudra attendre sa disponibilité pour s'en assurer. A-Data et OCZ ont d'ores et déjà annoncé qu'ils produiront des SSD basés sur ces contrôleurs.

Les contrôleurs : qui utilise quoi ?

Voici un tableau récapitulant les contrôleurs et le type de mémoire utilisé par les principaux modèles de SSD PCI-Express, SATA 2.5" et SATA 3.5" (les modèles 1.8", PATA, eSATA et ceux vendus sous la marque du fabricant du contrôleur ne sont

pas listés ici) :

° les contrôleurs Toshiba utilisé par Kingston sur ces modèles de SSD sont des contrôleurs Jmicron, mais doté de firmwares élaborés par Toshiba. Sur le JMF602, le firmware Toshiba résoud une bonne partie des problèmes de performances sur les petits accès, mais au prix d'une grosse baisse des performances en séquentiel.

°° le contrôleur est d'origine Jmicron, mais Western Digital a développé un firmware spécifique, très différent de l'original.

Notez que le plus souvent, les SSD issus de constructeurs différents mais embarquant le même contrôleur sont en fait strictement identiques. C'est particulièrement le cas avec les modèles à base de contrôleurs Intel et Samsung, pour lesquels seule l'étiquette change, Intel et Samsung ne vendant que des produits complets, pas des contrôleurs seuls.

Conseils d'utilisation

Maintenant que nous avons vu la théorie, passons à la pratique, avec quelques conseils de base pour optimiser les performances des SSD en tenant compte de leur spécificités. Vous pourrez trouver des astuces plus détaillées sur certains forums spécialisés, et en particulier sur la section dédiée au SSD du forum d'OCZ.

L'alignement des partitions

Les systèmes de fichiers sont découpés en clusters, dont la taille fait généralement 4 Ko. Pour des performances optimales, il faut absolument que les "frontières" séparant ces secteurs coïncident avec les frontières des pages et des blocs pour éviter des opérations inutiles. En effet, si la frontière entre deux clusters tombe au milieu d'une page, une écriture sur ce cluster obligera à écrire une partie du cluster suivant et/ou du cluster précédent.

Pour assurer cette coïncidence, il faut que la partition soit correctement alignée, c'est-à-dire qu'elle doit commencer à une adresse logique multiple de la taille des pages, et, de préférence, multiple de la taille des blocs. En cas de montage RAID0 ou RAID5, il est également préférable d'aligner sur la taille des bandes RAID.

Ce point est particulièrement important avec les SSD peu performants, comme ceux à base de Jmicron JMF602. Les tests montraient par exemple des performances radicalement différentes sur ces SSD entre un Windows XP en configuration par défaut (partitions débutant an 64ème secteur, ce qui tombait au milieu d'une page) et un Windows XP avec partitions réalignées au 65ème ou au 129ème secteur.

Windows Vista et Windows 7 alignent pour leur part à 1 Mo, ce qui convient à tous les SSD actuels, même avec des grosses tailles de clusters.

Du côté de Mac OS X, l'alignement de la partition EFI de 200 Mo est à 512 octets, ce qui n'est idéal que si les clusters de cette partition font 512 octets (mais cette partition est très peu utilisée, donc ce n'est pas problématique si son alignement est incorrect), tandis que la première partition du disque est alignée à 204 820 Ko, ce qui ne convient que pour des clusters d'un maximum de 4 Ko (ça tombe bien, c'est la taille par défaut pour les clusters sous OS X :-) ).

Éviter les écritures inutiles

Dans la mesure du possible, évitez l'écriture de fichiers temporaires et de cache (cache du navigateur par exemple) sur les SSD. Ces écritures vont en effet engendre des effacements (donc de l'usure) inutiles et vont augmenter la fragmentation physique, donc dégrader les performances.

Pour les fichiers temporaires, ils ne sont normalement pas écrits sur le disque, tant que la RAM est suffisante et si les logiciels créant ces fichiers le font proprement (en flagant le fichier comme temporaire lors de sa création, ce qui incitera l'OS à le garder le plus longtemps possible dans son cache de fichiers, sans l'écrire sur le volume).

Pour les logiciels ne gérant pas leurs fichiers temporaires proprement, la meilleure solution est d'utiliser un ramdisk non persistant.

Pour les fichiers de cache, l'idéal est de les placer dans un ramdisk persistant. Ils ne seront ainsi écrit qu'une fois à chaque arrêt de la machine, et de manière séquentielle. De plus, les performances en lecture et écriture des fichiers de cache seront grandement améliorées.

Vous trouverez des informations sur la création de ramdisks persistants sous OS X et Windows sur mon blog.

**Si vous ne disposez pas de suffisamment de RAM pour créer des ramdisks, il est préférable de placer les caches sur SSD (pour profiter des excellents temps d'accès) et les fichiers temporaires sur disque dur (comme ils ne sont pas souvent écrits, les performanc

Bonjour Yankee 71100

Merci encore pour cette autre information que je ne connaissais pas et qui a une grande importance, surtout pour une catégorie d'utilisateurs.

Je pense qu'il y aura à l'avenir des progrès dans ce sens aussi, sinon, en attendant, attention encore une fois, ne pas prêter son PC, détruire son SSD en vendant son PC etc....

Bonjour Zekri

Ben Oui, il vaut mieux vendre son PC sans disque-dur SSD...Ou en mettre un vierge, sans données personnelles!....juste un Système installer sans compte utilisateur!.

Bonjour Yankee 71100

Merci encore pour cette autre information que je ne connaissais pas et qui a une grande importance, surtout pour une catégorie d'utilisateurs.

Je pense qu'il y aura à l'avenir des progrès dans ce sens aussi, sinon, en attendant, attention encore une fois, ne pas prêter son PC, détruire son SSD en vendant son PC etc....

Bonjour

Selon une étude réalisée par des ingénieurs du Département Informatique et Ingénierie de l'Université de Californie, les logiciels disponibles aujourd'hui pour effacer les données sur des disques durs magnétiques ne sont pas assez fiables pour être utilisés sur des disques durs « solid state drives » (SSD).

La destruction de fichiers sur les disques SSD problématique

Les chercheurs ont notamment mis en évidence une série de problèmes quant il s'agit de détruire des données de manière sécurisée, que ce soit l'effacement d'un disque SSD dans son ensemble ou la suppression de fichiers individuels inscrits sur ce type de disque. En premier lieu, ils font état de problèmes liés à la façon dont certains firmware de disque mettent en oeuvre les commandes ATA/SCSI pour effectuer la fonction d'effacement. Ceux-ci ont constaté que, parmi les douze disques SSD analysés, seuls quatre d'entre eux avaient complétement effacé l'empreinte utilisée pour le test. Parmi les huit disques restant, quatre ne prenaient pas en charge la fonction d'effacement des données, trois d'entre eux étant des disques amovibles USB, et l'un, crypté, n'a pu être vérifié. Trois autres disques n'ont pas permis d'aboutir : deux à cause de bugs dans le firmware, et le troisième indiquait que les données avaient été correctement effacées alors qu'elles étaient intactes et encore accessibles sur le disque.

Les résultats obtenus pour l'effacement d'un seul fichier sur un disque SSD à partir d'une série de protocoles standards de destruction ont été encore plus mauvais. Ainsi, il s'est avéré que 4 à 75% des données restaient récupérables. Dans le genre, les clés USB font piètre figure, avec un taux d'accès aux données « effacées » de 0,57% à 84,9%. L'équipe a même essayé de démagnétiser les disques avec un matériel recommandé par la NSA, pour confirmer que cette technique ne fonctionnait pas sur les disques à mémoire flash.

Une erreur d'emplacement

Le coeur du problème est que, contrairement aux supports magnétiques, les disques SSD enregistrent les données dans des pages physiques, mais effacent les blocs logiques d'adresses (LBA). Ce processus, géré par une couche appelée Flash Translation Layer (FTL), trompe le driver du contrôleur ATA ou SCSI, qui confond entre l'endroit où se trouvent les données et celui où elles résident physiquement. Le disque compense en recopiant les données et c'est cette copie qui laisse des traces qui ne sont pas effacées. « Ces différences de comportement réel entre les disques durs magnétiques et les disques SSD présentent un risque dans la mesure où il ne se produit pas la même chose et que, dans un cas, la demande de l'utilisateur n'est pas satisfaite, » disent les chercheurs. « Le propriétaire d'un disque SSD qui applique une méthode de destruction de données propres aux disques durs pense, à tort, que ses données seront irrécupérables. En réalité, les données demeurent sur le disque et il est possible de les récupérer sans avoir recours à des outils très sophistiqués. » En d'autres termes, l'hypothèse selon laquelle les techniques de destruction de données actuelles peuvent s'appliquer de la même manière sur les disques SSD et sur les supports à mémoire flash en général est aussi erronée. Parfois, cela marche, parfois non. Cela dépend de la qualité de l'intégration et s'il s'agit ou non de fichiers uniques.

La difficulté de nettoyer de simples fichiers sur des disques SSD va alerter les administrateurs IT, parce que c'est pour eux une exigence quotidienne. Comment par exemple, être sûr de détruire des clés de chiffrement, des fichiers de tableur et autres documents importants sans altérer l'ensemble du disque. Les chercheurs suggèrent plusieurs techniques qui permettraient de modifier le Flash Translation Layer (FTL) du SSD pour répondre à ces besoins en sécurité.