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 sont actuellement utilisés comme mémoire de stockage, au même titre que les disques durs. Ils tendent de plus en plus à remplacer complètement les disques durs, ce qui fait qu'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
2 - Contrôleur de mémoire FLASH et de port USB.
3 - Connecteurs utilisés pour divers tests.
4 - Puce de mémoire Flash.
5 - Générateur d'horloge interne.
6 - LED d'activité.
7 - Switch pour autoriser/interdire les écritures.
8 - Circuit imprimé.
Comme 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
Comme 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
L'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. A 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.
 Micro-architecture d'une mémoire Flash de type NAND. |
 Pages et blocs. |
Le processus de lecture/écriture d'une page mémoire
Vu 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.
La correspondance d'adresse dans le Flash transaction layer
Le 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
Dans 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
Pour 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. Mais pour cela, 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 correspondance dynamique permet d'appliquer des optimisations qui simplifient considérablement les écritures. La correspondance dynamique permet de faire ce que l'on appelle du relocate on write, du réassignement lors de l'écriture. Avec cette technique, 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. A force de déplacer les pages d'une écriture à l'autre, certains blocs sont complètement rempli de pages invalides et sont donc bons pour être effacés. De tels blocs sont appelés des blocs invalides. L'effacement des blocs invalides est effectué plus tard, quand le SSD est inutilisé. 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.
Reste que cette 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. A 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
Certains 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
De nombreux phénomènes font que les écritures sont multipliées sur les SSD : chaque écriture demandée par le système d'exploitation va se traduire par plusieurs écritures à l'intérieur du SSD. Ce phénomène d'amplification d'écriture a plusieurs raisons. 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
Pour 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
Autre 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
Les algorithmes de garbage collection ont une limite : ils fonctionnent au niveau du matériel. Or, une donnée peut parfaitement devenir inutile et être quand même présente sur le disque dur. C'est le cas sur beaucoup de système d'exploitation actuels : quand on supprime un fichier, ils n'effacent pas réellement les données, mais se contentent d'oublier leur localisation sur le disque dur. Les données sont toujours là, mais le système d'exploitation a modifié ses tables qui lui permettent de savoir où est le fichier sur le disque dur, rendant celui-ci inaccessible. Mais pour le SSD, ces données sont toujours présentes sur le disque dur, 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é
L'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
L'architecture d'un SSD peut permettre des optimisations, afin de manière à gagner en performances. Les optimisations en question sont souvent les mêmes que celles utilisées sur les mémoires RAM : entrelacement, pipeline, etc. Voyons-les plus en détail.
Le pipelining et l'entrelacement
Pour ce qui est du pipeline, dans sa forme la plus simple, les Flash se limitent à recevoir une requête de lecture/écriture pendant que la Flash effectue la précédente. Pour cela, le contrôleur de la Flash doit être modifié et chaque bloc se voit attribuer un registre de cache, pour 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 : 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. É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.
Une seconde optimisation est l'utilisation de banques mémoires séparées, comme pour les autres mémoires adressables (RAM, ROM, autres). La mémoire FLASH est structurée en plusieurs banques, qui sont accessibles en parallèle. 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. Dans le meilleur des cas, on a un accès par banque, ce qui fait autant d'accès simultanés qu'il y a de banques. En utilisant correctement l'organisation en banques, on peut arriver à pipiliner les accès mémoire. Mais cela demande des accès mémoires séquentiels ou du moins assez bien répartis dans la mémoire. Précisons que les banques des mémoires FLASH s’appellent des planes.
Les optimisations de la gestion des requêtes
Le Flash Transaction Layer gère les requêtes envoyées par le processeur. Mais cette gestion n'est pas gratuite et demande un circuit dédié, similaire à celui que l'on trouve sur les disque durs. Ce circuit est relativement simple : il s'agit le plus souvent d'une simple file d'attente dans laquelle les requêtes vont attendre que le support de mémorisation doit disponible. Ajouter cette file d'attente évite au processeur d'attendre qu'une requête soit terminée pour envoyer la suivante, et permet ainsi d'augmenter le nombre de requêtes traitées par seconde. Mais en utilisant correctement cette file d'attente, le Flash Transaction Layer peut effectuer quelques optimisations, comme changer l'ordre d'accès des requêtes, accéder à des banques en parallèle, etc. Voyons en détail les optimisations de ce genre les plus courantes.
Le Flash transaction Layer peut profiter du fait que des banques séparées peuvent être accédés en parallèle. Cela demande de changer l'ordre des requêtes de manière à éloigner les requêtes destinées à une même banque. L'idéal est que des requêtes consécutives accèdent à des banques distinctes. 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. C'est la technique du Multi-plane rescheduling. On peut aussi fusionnant plusieurs requêtes de lecture/écriture en une seule requête d'écriture/lecture envoyée aux banques en parallèle.
Une autre solution consiste à mettre les écritures en attente dans une mémoire tampon : le write buffer. Cette mémoire cache sert juste à accumuler les écritures, et mémorise la donnée à écrire et l'adresse physique de la page à modifier. Ce tampon peut permettre de réorganiser les écritures de façon à gagner en performance, mais son utilité principale est de fusionner plusieurs écritures en une seule. Si plusieurs écritures sur la même page sont mises en attente, alors on peut les fusionner et ne garder que la dernière, la seule à avoir la donnée la plus à jour. Mais cela demande quelques conditions, notamment l'absence de lectures en attente de la dite page.
Les optimisations du réassignement lors de l'écriture
Certaines 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.