Fonctionnement d'un ordinateur/Les solid-state drives
De nos jours, les disques durs tendent à être remplacés par des mémoires de masse dont le support de mémorisation est électronique : les solid-state drives, ou SSD. Certains SSD assez anciens utilisaient de la mémoire DDR-SDRAM, comme on en trouve dans nos PC, mais les SSD actuels sont fabriqués avec de la mémoire Flash. Il s'agit d'une forme évoluée d'EEPROM, déclinée en plusieurs versions : NOR et NAND. De telles mémoires sont plus rapides que les mémoires magnétiques, ce qui fait que les SSD sont naturellement plus rapides que leurs cousins mécaniques. Par contre, leur capacité est censée être plus faible bien que l'évolution de la technologie tende de plus en plus à faire mentir ce point.
Les SSD tendent de plus en plus à remplacer complètement les disques durs et il n'est pas rare de voir des ordinateurs avec seulement un SSD et aucun disque dur interne. Mais cela n'a pas toujours été le cas. Les premiers SSD avaient une capacité mémoire assez faible et on ne pouvait pas y mettre grand chose dessus. En conséquence, ils étaient utilisés en complètement d'un disque dur normal de grande capacité. Le système d'exploitation et les programmes les plus utilisés étaient placés sur le SSD, alors que les documents, films, jeux vidéos et autres données de grande taille étaient placées sur le disque dur. Cela permettait de profiter partiellement de la performance du SSD, tout en gardant un disque dur de grande capacité à côté. Mais cette technique de dual drive commence de plus en plus à faire sa place au SSHD, à savoir l'utilisation d'un SSD comme seul et unique disque dur. Les SSD ont en effet gagnés en capacité mémoire avec l'évolution de la technologie, ce qui les rend presque aussi gros de les anciens disques durs. L'usage d'un disque dur complémentaire devient de moins en moins utile de ce fait.
Précisons, avant de poursuivre ce chapitre, que les clés USB fonctionnent exactement comme les SSDs et leurs architectures internes sont similaires. Elles contiennent elles aussi de la mémoire FLASH, entre un et plusieurs boîtiers. Mais la capacité mémoire d'une clé USB est bien plus faible que celle d'un SSD et elles ont une micro-architecture plus simples, avec moins d'optimisations et de technologie avancées. La plupart des concepts vus dans ce chapitre s'appliquent aussi bien aux clés USB qu'aux SSD, seule la toute dernière partie (sur les optimisations) étant spécifique aux SSD.
La micro-architecture des SSD et des clés USB
modifierComme toutes les mémoires, un SSD contient un support de mémorisation, et des circuits annexes qui permettent de gérer ce support. Le support de mémorisation est de la mémoire FLASH, à savoir une forme de mémoire EEPROM accessible via un bus série (sauf pour quelques exceptions). Un SSD contient plusieurs boîtiers de mémoire FLASH, là où les clés USB n'en contiennent parfois qu'une seule. Pour ce qui est du reste, l'organisation interne d'un SSD est similaire à celle d'un disque dur dont on aurait remplacé les plateaux par de la mémoire FLASH. On y retrouve un contrôleur de bus, qui permet au SSD de communiquer avec le reste de l'ordinateur via un bus S-ATA, P-ATA, ou SCSI (comme pour les autres disques durs).
À côté du support de mémorisation, on trouve un contrôleur de mémoire FLASH, qui gère la mémoire FLASH du SSD. Le contrôleur de mémoire FLASH est souvent appelé le Flash Transaction Layer, et nous utiliserons ce terme par la suite. Il reçoit les requêtes de lecture ou d'écriture, et commande les mémoires FLASH pour les exécuter. Ce contrôleur fait en sorte que le SSD soit vu comme un disque dur par le processeur, et non comme un amas de mémoire FLASH. Le contrôleur de mémoire FLASH est souvent un processeur auquel on a rajouté une mémoire DRAM ou SRAM (voire les deux). Pour contenir le programme que doit exécuter ce processeur, le SSD incorpore parfois une mémoire ROM. Mais dans d'autres cas, une portion de la mémoire FLASH du disque dur sert à stocker le Firmware. Il n'est pas rare, sur les clés USB, que le contrôleur de bus et le contrôleur de FLASH soient fusionnés en un seul circuit.
De plus, on trouve de nombreux circuits intercalés entre l'interface série des boîtiers de FLASH et l'interface avec le bus. Les plus importants sont de loin les circuits de conversion série-parallèle, qui servent à convertir ce qui sort des mémoires FLASH en données parallèles. Cette conversion sert à faciliter les transferts entre FLASH et bus externe. Rappelons en effet que les FLASH ont une interface série, là où les bus ATA et SCSI sont parallèles. Un SSD digne de ce nom contient aussi des mémoires tampons de type FIFO pour mettre en attente des données lues ou à écrire, afin d'accepter un grand nombre de requêtes de lecture/écriture pendant que les mémoires FLASH sont encours d'utilisation. Quelques circuits annexes se chargent de la gestion de ces files d'attente, files d'attente qui seront abordées à la fin de ce tutoriel. Enfin, on peut trouver des circuits de correction et de détection d'erreur.
Le support de mémorisation : la mémoire Flash de type NAND
modifierComme dit plus haut, le support de mémorisation d'un SDD est un paquet de mémoires FLASH. Reste à savoir laquelle, car il existe plusieurs types de mémoire Flash. Nous avons déjà parlé du fonctionnement de la mémoire FLASH dans les chapitres précédents. Nous y avions notamment vu la différence entre EEPROM, FLASH de type NOR et FLASH de type NAND. Et bien sachez que la quasi-totalité des SSD actuels sont fabriqués à base de FLASH de type NAND, qui est moins chère mais a une interface d'adressage plus complexe. La simplicité d'adressage des FLASH NOR est contrebalancée par leur coût plus élevé, qui les rend impraticables pour la fabrication de disque durs.
Parlons rapidement de l'interface de ces mémoires FLASH. Les premières mémoires FLASH étaient accessibles en lecture ou écriture via un bus série : on ne pouvait lire ou écrire qu'un seul bit à la fois. De nos jours, les mémoires FLASH peuvent communiquer avec l'extérieur via des bus parallèles : on peut lire ou écrire plusieurs bits à la fois. Mais dans ce qui va suivre, nous parlerons surtout des mémoires FLASH série, beaucoup utilisées dans les SSDs, surtout les anciens.
Rappels sur les mémoires Flash de type NAND
modifierL'interface d'une Flash NAND autorise plusieurs opérations : la lecture, l'écriture (ou reprogrammation, vu qu'il s'agit d'une mémoire EEPROM) et l'effacement. Rappelons la différence entre écriture et effacement sur les mémoires de type EEPROM : on peut écrire dans une EEPROM si elle est vide, mais pas si elle contient des données. Si une EEPROM contient des données, on doit l'effacer avant de pouvoir y réécrire quelque chose. C'est la même chose pour les mémoires FLASH de type NAND, à un détail près : on ne peut pas effacer ou écrire byte par byte. À la place, la FLASH est découpée en plusieurs unités que l'on doit effacer ou reprogrammer en entier. Précisons immédiatement que ces unités n'ont pas la même taille selon l’opération demandée. Pour le dire autrement, elles ont des tailles différentes selon que l'on effectue un effacement, une lecture ou une écriture. Par exemple, il est possible de lire un octet individuel, d'écrire par paquets de 512 octets et d'effacer des paquets de 4096 octets.
Pour résumer, une mémoire FLASH de type NAND est décomposée en blocs, eux-même composés de plusieurs pages mémoire. L'écriture s'effectue par paquets de plusieurs bytes, qui sont appelés des pages mémoires, ou encore des pages. Il est possible d'écrire dans une page vide complète, mais il est impossible d'écrire dans un bit ou un octet individuel : l'écriture se fait par pages entières. Même si vous ne voulez modifier qu'un seul bit ou un seul secteur, vous allez devoir modifier une page de 512 à 4096 octets. Elles ont une capacité mémoire de 512 octets pour les plus anciens SSD à environ 4 kibioctets sur les modèles normaux. Par contre, l'effacement s’effectue par blocs d'une taille supérieure. Typiquement, un bloc fait dans les 64 kibioctets, ce qui signifie qu'il contient systématiquement plusieurs pages mémoire. Cela veut dire qu'il est impossible d'effacer une seule page mémoire : on est obligé d'effacer un bloc complet de plusieurs pages d'un seul coup. Cela pose quelques problèmes lors des écritures. Si une page est vide, il n'y a pas de problèmes : on peut écrire dans celle-ci sans problème, même si les autres pages du bloc sont occupées. Mais si la page contient déjà des données, on est obligé d'effacer tout le bloc. Ce problème est géré différemment suivant le SSD, comme on le verra dans la suite du cours.
Comme pour toutes les autres mémoires, une mémoire FLASH peut être organisée en banques mémoires séparées, accessibles en parallèle. Précisons que les banques des mémoires FLASH s’appellent des planes. Avec une seule banque, sans l'optimisation, on ne peut faire qu'un accès mémoire à la fois. Par contre, avec plusieurs banques, on peut avoir plusieurs accès en parallèle, si certaines conditions sont remplies. Toutes les techniques d'entrelacement et de pipelining sont utilisables avec les banques des mémoires FLASH. Il est aussi possible de changer l'ordre des accès mémoire de manière à ce que des requêtes consécutives accèdent à des banques distinctes : c'est la technique du Multi-plane rescheduling. On évite ainsi des conflits d'accès, une requête est mise en attente pendant que la banque est occupée avec une autre. Mais cela demande de remettre en ordre les résultats de lecture/écriture, avec divers circuits semblables à ceux vus dans le chapitre sur le contrôleur mémoire des RAM.
Le processus de lecture/écriture d'une page mémoire
modifierVu que les pages font plusieurs kibioctets, il est évident que les Flash NAND ne peuvent pas utiliser une interface parallèle : vous imaginez des bus de 4096 bits ? À la place, elles sont obligées d'utiliser des bus série pour envoyer ou récupérer les pages bit par bit. Pour faire la conversion série-parallèle, chaque plane ou bloc contient un registre à décalage série-parallèle : le registre de page.
Lors d'une lecture, les bits sont lus un par un et sont accumulés dans le registre de page, avant d'être envoyés sur la sortie de la mémoire Flash.
L'écriture se déroule différemment, en raison de l'organisation en pages/blocs. Le processus n'est pas le même si la page à écrire est vide que lorsqu'elle est déjà remplie. Si la page à écrire est vide, alors les bits à écrire sont copiés dans le registre de page, qui les envoie un par un dans la FLASH. Si la page est déjà remplie, on doit faire la même chose, sauf qu'il faut effacer le bloc avant, tout en conservant intactes les autres pages. Ce dernier point pose évidemment problème : comment sauvegarder les autres pages ? La solution la plus simple est de sauvegarder temporairement tout le contenu du bloc à effacer, sauf la page à écrire. Dans le cas le plus simple, le registre de page est simplement agrandit pour pouvoir stocker un bloc complet (les modifications d'une page s’effectuant directement dans ce registre de bloc). Le bloc à effacer est recopié dans le registre de page avant une écriture, la page est modifiée dans le registre, le bloc est effacé et le résultat est écrit dans le bloc. Mais dans le cas le plus courant, le bloc à effacer est simplement recopié dans un autre bloc, sans la page à modifier : la page à modifier est alors une page vide, qui peut être écrite directement. On verra comment cela est possible dans la suite de chapitre, quand nous parlerons de correspondance dynamique.
Le pipelining des accès mémoire
modifierUn accès mémoire à un SSD se fait donc globalement en deux temps. Pour une lecture, on lit la donnée et on la copie dans le registre de page, puis on la transfère bit par bit sur l'interface série. Pour une écriture, c'est l'inverse : la première étape copie la donnée à écrire dans le registre de page, puis la donnée passe du registre de page à la page mémoire. Sur une mémoire Flash normale, les deux étapes doivent se terminer avant qu'on démarre un nouvel accès. Mais il est possible de faire en sorte de démarrer une nouvelle lecture/écriture une fois la première étape terminée.
Pour cela, chaque plane ou bloc se voit attribuer un registre supplémentaire, en plus du registre de page : le registre de cache. Pour simplifier, ce registre de cache sert de second registre de page. On peut alors faire un transfert entre le premier registre de page et le support de mémorisation, pendant que le second registre de page fait un transfert sur l'interface série. Évidemment, le contenu des registres de page et de cache est échangé à chaque début de lecture/écriture. Avec quelques optimisations, on peut se passer de recopies en échangeant le rôle des registres : le registre de page devient le registre de cache, et vice versa.
Prenons l'exemple de deux écritures successives : ce registre de cache permet de mettre en attente une écriture pendant que la précédente utilise le registre de page. La donnée en cours d'écriture est copiée du registre de page sur le support de mémorisation, tandis que le registre de cache accumule les bits de la prochaine donnée à écrire.
Pour une lecture, c'est la même chose. Pendant qu'une donnée est chargée dans le registre de page, celui-ci est inutilisable et ne peut envoyer son contenu vers l'extérieur. Mais avec un registre de page, c'est différent : le contenu du registre de cache peut être envoyé sur la sortie série, pendant qu'une autre donnée est copiée du support de mémorisation vers le registre de page.
La correspondance d'adresse dans le Flash transaction layer
modifierLe support de mémorisation est géré par deux contrôleurs. Le premier est un contrôleur qui joue le même rôle que le contrôleur mémoire pour les DRAM. Il gère les requêtes de lecture et d'écriture qui utilisent des adresses physiques, qui sont directement compréhensible par de la mémoire FLASH. Le système d'exploitation transmet au SSD des adresses de secteurs (des adresses LBA), qui sont traduites en adresses de mémoire FLASH par le contrôleur de SSD. La majorité des SSD (si ce n'est tous) partent du principe qu'un secteur est égal à une page. Suivant la complexité du SSD, il existe différentes méthodes pour gérer cette correspondance. Mais on peut les classer en deux types : la correspondance statique et la correspondance dynamique.
La correspondance statique
modifierDans le cas le plus simple, la correspondance entre adresse LBA et adresse de mémoire Flash est fixée une fois pour toutes à la construction du SSD : on parle alors de correspondance statique. Dans le cas le plus simple, l'adresse LBA est identique à l'adresse physique : pas besoin de traduction. Dans la réalité, il se peut que certains bits de l'adresse soient échangés, afin de répartir des adresses LBA consécutives dans des planes ou blocs différents, histoire de profiter de l'entrelacement.
Cette correspondance statique effectue les écritures en place, à savoir que toute réécriture d'une page demande d'effacer le bloc complet. On doit donc sauvegarder temporairement le bloc dans le registre de page, mettre à jour la page à écrire dans le bloc, effacer le bloc et réécrire le résultat, comme on l'a vu plus haut. Mais on peut cependant faire mieux, dans le cadre de la correspondance dynamique.
Mais la correspondance statique a un autre problème, bien plus grave celui-ci : elle réduit la durée de vie du SSD. En effet, les cellules de mémoire Flash ne peuvent supporter qu'un nombre limité d'effacements. Et avec une correspondance statique, certaines cellules seront nettement plus souvent réécrites que d'autres : après tout, certains fichiers sont très souvent accédés, tandis que d'autres sont laissés à l'abandon. Certaines cellules vont donc tomber en panne rapidement, ce qui réduit la durée de vie du SSD.
La correspondance dynamique
modifierPour régler ces problèmes, certains contrôleurs utilisent une correspondance dynamique : la position d'une adresse LBA dans la mémoire Flash est variable et peut changer si le besoin s'en fait sentir.
La correspondance dynamique permet d'appliquer des optimisations qui simplifient considérablement les écritures. Elle permet notamment ce que l'on appelle du relocate on write, du réassignement lors de l'écriture. Avec cette technique, lors d'une écriture, la page à écrire est écrite dans un bloc vide et l'ancienne page est marquée invalide. L'adresse LBA d'un secteur change donc à chaque écriture, la page associée n'ayant pas de place fixe sur le SSD. À force de déplacer les pages d'une écriture à l'autre, certains blocs sont complètement rempli de pages invalides, bons pour être effacés. L'effacement des blocs invalides est effectué plus tard, quand le SSD est inutilisé, ou quand le besoin s'en fait sentir. Pour cela, le SSD possède une liste des pages vierges et des blocs en attente d'effacement, qui est utilisée par le contrôleur de Flash pour effacer les blocs invalides. Cette méthode accélère les écritures : on n'a plus besoin d'effacer la page avant d'écrire dedans, l'écriture se fait immédiatement et l'effacement se fait soit en parallèle, soit plus tard. D'autres optimisations sont rendues possibles par la correspondance dynamique, mais nous en parlerons plus loin. Pour le moment, concentrons-nous sur la manière dont la correspondance dynamique est implémentée.
Avec la correspondance dynamique, le SSD doit se souvenir à quelle page ou bloc correspond chaque adresse LBA, et réciproquement. Pour cela, il contient à une table de correspondance adresses LBA <-> adresse de mémoire FLASH, qui est mémorisée soit dans une mémoire non volatile, soit dans les premiers secteurs du SSD. La plupart des SSDs en vente actuellement utilisent une mémoire RAM interne pour stocker une copie de la table, la RAM en question étant appelée à tort le DRAM cache. Le SSD charge la table de correspondance dans ce DRAM cache à l'allumage. Toute modification de la table de correspondance est répercutée à la fois dans la la copie en mémoire DRAM, mais aussi dans l'EEPROM ou le premier secteur. L'accès au DRAM cache est très rapide, comparé à un accès direct au premier secteur ou à l'EEPROM, qui ont un temps d'accès assez important. En conséquence, toute opération qui demande d'utiliser la table de correspondance est accélérée, et cela inclut les lectures, écritures et d'autres opérations. Quelques SSD à petit prix se passent de ce DRAM cache, afin d'économiser les quelques euros que coutent le DRAM cache, mais leur performances sont assez mauvaises.
Reste que la correspondance d'adresse peut se faire de trois manières : soit le contrôleur travaille au niveau de la page, soit il travaille au niveau du bloc, soit il utilise une technique hybride.
- Dans le premier cas, un secteur peut se voir attribuer n'importe quelle page, peu importe le bloc où se situe la page. Rien n'oblige des secteurs consécutifs à être dans un même bloc.
- Dans le second cas, des secteurs consécutifs sont placés dans le même bloc, dans des pages différentes. La position de la page dans un bloc est déterminée statiquement, mais le bloc dans lequel placer la donnée change.
- Dans le troisième cas, le contrôleur utilise une table de correspondances par bloc pour les lectures, avec un mise à jour par page lors de l'écriture.
Les correspondance par page et par bloc sont souvent opposées, la première ayant l'avantage d'avoir une meilleure souplesse d'adressage, alors que la seconde donne une table de correspondance d'adresse beaucoup plus petite. En effet, la correspondance dynamique par page a un gros désavantage : vu qu'il faut une correspondance pour chaque page, la table de correspondance a besoin de beaucoup de mémoire. Par exemple, un disque dur de 64 gibioctets contiendra 16 mebi pages : il y a donc 16 777 216 correspondances, ce qui fait une table de plusieurs centaines de mébioctets. Difficile à tenir sur les SSD actuels sans grosses pertes de performances. La situation est nettement meilleure pour la correspondance par bloc. Vu qu'il y a plusieurs pages par bloc, la table prend donc nettement moins de place que son équivalent par page.
Voyons maintenant rapidement les techniques hybrides. La première technique hybride, celle du log blocks, groupe les blocs en deux catégories : les blocs de données gérés avec un adressage par bloc, et des blocs de journalisation gérés avec un adressage par page. Vu le faible nombre de blocs de journalisation, la table de correspondance associée est relativement petite. Quand un bloc est écrit, un bloc de journalisation vide est sélectionné pour accueillir la donnée écrite. À cette occasion, l'adresse LBA de la page est mémorisée dans les bits de contrôle de celle-ci. Pour une lecture, le FTL doit commencer par vérifier la table de correspondance des blocs de journalisation : on lit le bloc de journalisation qui correspond si une correspondance est trouvée, et on utilise la table de correspondance des blocs de données dans le cas contraire. Depuis, d'autres techniques hybrides ont vu le jour, de nombreux travaux académiques sur le sujet sont disponibles sur le net, et les brevets déposés par les industriels sont aussi relativement nombreux.
Le Wear leveling
modifierCertains contrôleurs de SSD utilisent une technique pour augmenter la durée de vie du SSD : le wear leveling, ou égalisation d'usure. L'idée est simple : on va chercher à répartir les écritures de manière à ce que tous les blocs soient « usés » de la même façon : on va faire en sorte que le nombre d'écritures soit identique dans tous les blocs. Pour cela, il suffit de déplacer les données fortement utilisées dans des blocs pas vraiment usés. Vu que les données fréquemment utilisées sont présentes sur des blocs très usés, qui ont un grand nombre d'écriture, on peut considérer que le wear leveling consiste à déplacer les données des blocs usés dans les blocs relativement intacts.
Le plus simple est le wear leveling dynamique, où les blocs sont déplacés lorsqu'ils sont réécrits. Quand on veut réécrire une donnée, on va choisir un bloc qui a relativement peu d'écritures a son actif. Pour cela, le contrôleur de SSD doit mémoriser le nombre d'écritures de chaque bloc dans une mémoire non-volatile. Avec ce wear leveling dynamique, les données qui ne sont pas réécrites souvent ne bougent quasiment jamais du bloc qui leur est assigné, ce qui est loin d'être optimal. Il vaut mieux déplacer des telles données sur des blocs très usés, et allouer leur emplacement initial à une donnée fréquemment mise à jour. C'est ce principe qui se cache derrière le wear leveling statique. Il va de soi que le contrôleur doit alors mémoriser la liste des blocs peu utilisés, en plus de la liste des blocs vides.
L'amplification d'écriture
modifierDe nombreux phénomènes font que les écritures sont multipliées sur les SSD, c’est-à-dire qu'il arrive qu'une écriture demandée par le système d'exploitation se traduise par plusieurs écritures à l'intérieur du SSD. Ce phénomène d'amplification d'écriture a plusieurs causes. Déjà, le wear leveling ajoute des écritures supplémentaires en déplaçant des blocs. Mais le responsable principal est l'optimisation de réassignement lors de l'écriture, vue plus haut. Avec elle, chaque écriture se fait dans une nouvelle page, ce qui gaspille le bloc/la page qui contient l'ancienne version de la donnée écrite. Si un secteur est écrit six fois de suite, six blocs ou six pages seront utilisés pour mémoriser ce secteur dont un seul contiendra une donnée valide : ce qui fait un gâchis de cinq blocs/pages. Un SSD tomberait rapidement à court de pages si les constructeurs n'avaient pas déjà pris la mesure du problème. Mais évidemment, les SSDs contiennent de nombreuses méthodes pour limiter la casse.
Le sur-approvisionnement
modifierPour limiter la casse, certains SSD contiennent des FLASH en rab : on parle de sur-approvisionnement. Ces FLASH sont placées dans le SSD et sont invisibles du point de vue du système d'exploitation. Ces FLASH en rab peuvent aussi servir si jamais une mémoire FLASH tombe en panne après avoir été trop souvent écrite, il suffit de la remplacer par une FLASH en rab. Ce remplacement s'effectue simplement en changeant la correspondance entre l'adresse LBA et l'adresse physique : il suffit de remplacer l'adresse physique de la FLASH défectueuse par celle de la FLASH de rechange.
Le ramasse-miettes
modifierAutre solution : le SSD peut profiter de ses périodes d'inactivité pour se défragmenter tout seul. Il peut, plus précisément, réorganiser les données sur le disque dur afin de récupérer les pages invalides. Pour cela, le SSD doit déplacer les données des pages de manière à obtenir des blocs totalement vides, qu'il pourra alors effacer. Ces méthodes de ramasse-miettes (garbage collection) permettent de récupérer de l'espace libre, dans une certaine limite. Elles sont effectuées dans un circuit spécialisé, qui peut commander la mémoire FLASH indépendamment du Flash Transaction Layer. Ce garbage collector a toutefois un défaut : il est obligé de migrer des pages dans la mémoire FLASH, ce qui est à l'origine d'écritures supplémentaires. Cela aggrave encore l'amplification d'écriture.
La procédure pour récupérer les pages invalidées est assez complexe. Dans le cas le plus simple, les pages valides du bloc sont copiées dans un bloc vide, et l'ancien bloc est effacé. Dans d'autres cas, les pages valides sont copiées dans les pages vides d'un bloc déjà occupé, ce qui permet de remplir les vides et évite d'effacer un bloc inutilement. Et enfin, si toutes les pages d'un bloc sont invalides, alors le bloc est simplement effacé sans copie de pages.
La commande TRIM
modifierLes algorithmes de garbage collection ont une limite : ils fonctionnent au niveau du matériel. Or, une donnée peut devenir inutile et être quand même présente sur le disque dur. Les systèmes d'exploitation modernes n'effacent pas réellement les données quand on supprime un fichier, mais se contentent d'oublier leur localisation sur le disque dur. Les données sont toujours là sur le SSD, et les pages qu'elles occupent ne sont pas effacées : elles sont inutilisables et prennent de la place pour rien. Dans ces conditions, de nombreuses pages sont gâchées et l'espace libre du SSD diminue rapidement.
Pour éviter ce genre de problème, les constructeurs de SSD ont ajouté une commande au protocole de communication avec le disque dur : la commande TRIM. Celle-ci permet au système d'exploitation d'indiquer au SSD les secteurs qui correspondent à des fichiers supprimés. Ainsi, quand l'OS supprime un fichier, il peut avertir le SSD que les pages qui correspondent au fichier doivent, et peuvent être effacées. Cela permet d'éviter de gâcher des pages, et permet aux algorithmes de ramasse-miettes de fonctionner plus efficacement.
L'effacement sécurisé
modifierL'amplification d'écriture est à l'origine d'un autre problème, qui concerne les situations où l'on veut effacer des données sans que qui que ce soit ne puisse les récupérer. Avec des technologies de pointe, il est parfois possible de récupérer physiquement des données présentes sur un disque dur, même si celui-ci est partiellement détruit ou que les données en question ont été écrasées. Pour éviter cela, il vous suffit de réécrire des données aléatoires ou des zéros sur les secteurs concernés plusieurs centaines ou milliers de fois de suite. Mais si vous essayez de faire cela avec des SSD, cela n'effacera pas les données : cela se contentera de prendre des blocs vides pour écrire les données aléatoires dedans. Pour régler ce problème, certains SSD modernes possèdent des commandes qui permettent de remettre à zéro l'intégralité du disque dur, ou d'effacer des pages ou blocs bien précis.
Les optimisations internes aux SSDs
modifierL'architecture d'un SSD peut permettre des optimisations, afin de manière à gagner en performances. Nous avons déjà parlé du réassignement lors de l'écriture, mais cette optimisation est loin d'être la seule. Un partie de ces optimisations est rendue possible par la correspondance dynamique : c'est le cas du réassignement lors de l'écriture, qui a besoin de la correspondance dynamique pour fonctionner. Mais d'autres optimisations fonctionnent avec ou sans correspondance dynamique. Les optimisations en question sont souvent les mêmes que celles utilisées sur les mémoires RAM : entrelacement, pipeline, amélioration de la gestion des requêtes, usage de caches, etc. Voyons-les plus en détail.
Les optimisations du réassignement lors de l'écriture
modifierCertaines Flash permettent d'effectuer des copies rapides entre pages, opérations très courantes sur les SSD, sans passer par le registre de page. Mais cela a un coût : il faut que les pages en question soient reliées avec un lien série pour transférer les données de page en page. Et plus une mémoire Flash contient de pages, plus le nombre d'interconnexions augmente. Pour limiter le nombre d’interconnexions, ces copies rapides entre page ne sont possibles qu'à l'intérieur d'une plane ou d'un die : impossible de copier rapidement des données mémorisées dans des dies ou planes différents.
Le cache SLC
modifierDans le chapitre sur les cellules mémoire, nous avions vu qu'il existe plusieurs types de mémoire FLASH. Si on met de côté la distinction entre FLASH NAND et NOR, les FLASH se distinguent surtout par le nombre de bits que peut stocker une cellule mémoire. Pour simplifier, on peut faire la distinction entre les mémoires SLC (Single Level Cell) qui stockent un bit par cellule, et les mémoires MLC (Multi Level Cell) qui stockent 2, 3 voire 4 bits par cellules. Les mémoires SLC sont les plus rapides et elles ont une durée de vie supérieure, alors que les mémoires MLC ont des performances inférieures. Un SSD peut choisir d'utiliser soit de la mémoire SLC, soit de la mémoire MLC : il aura de bonnes performances et une mauvaise capacité mémoire avec la SLC, et inversement une bonne capacité mais de mauvaises performances avec la MLC.
Pour améliorer les performances tout en gardant une bonne capacité mémoire, certains SSD utilisent les deux à la fois. Les premiers secteurs du SSD sont fabriqués avec la FLASH SLC, alors que les autres sont en mémoire MLC. Les premiers secteurs sont utilisés comme un cache par le SSD, grâce à la correspondance dynamique. C'est à dire que les données qui sont beaucoup lues ou écrites sont placées dans les secteurs SLC, alors que les données peut utilisées sont placées en mémoire MLC. Ce faisant, le SSD gagne beaucoup en rapidité sur les données fréquemment utilisées, sans pour autant sacrifier énormément en capacité mémoire. Cette technique est appelée le cache SLC.