<\/p>\n\n
Les SSD (pour Solid State Drive<\/em>, contr\u00f4leur \u00e0 semi-conducteurs) sont des dispositifs qui utilisent autre chose que la technologie magn\u00e9tique des disques durs pour stocker des donn\u00e9es. Un appareil comme l\u2019iRAM est un SSD, par exemple, mais on utilise essentiellement l’acronyme pour les dispositifs \u00e0 base de m\u00e9moire flash.<\/p>\n\n <\/p>\n\n <\/p>\n\n Pour m\u00e9moire, dans le premier dossier qui date de mai 2007 nous testions des SSD en interface PATA, capables d’atteindre 50 Mo\/s en lecture pour le premier et 20 Mo\/s pour le second. La capacit\u00e9 \u00e9tait de 32 et 8 Go et le prix du mod\u00e8le de 32 Go fr\u00f4lait les 1 000 \u20ac. Actuellement, les SSD de la derni\u00e8re g\u00e9n\u00e9ration atteignent plus de 500 Mo\/s en lecture et offrent 512 Go de capacit\u00e9 pour le m\u00eame prix.<\/p>\n\n <\/p>\n\n MAJ<\/strong> : Consultez notre comparatif de SSD<\/a><\/p>\n La m\u00e9moire flash NAND est une m\u00e9moire de stockage qui utilise des transistors comme support. Son fonctionnement est bas\u00e9 sur l\u2019effet tunnel (plus pr\u00e9cis\u00e9ment l\u2019effet Fowler-Nordheim<\/em>).<\/p>\n\n <\/p>\n\n En simplifiant, les transistors utilis\u00e9s dans la m\u00e9moire flash contiennent deux grilles, une de contr\u00f4le et une deuxi\u00e8me, appel\u00e9e grille flottante, qui est en suspension dans un oxyde, le tout est plac\u00e9 sur un substrat qui contient deux \u00e9lectrodes.<\/p>\n\n <\/p>\n\n <\/p>\n\n Pour \u00e9crire une donn\u00e9e, on doit faire passer un courant \u00e9lectrique (7 V) entre les deux \u00e9lectrodes (drain et source) et une tension plus \u00e9lev\u00e9e (aux environs de 12 V) dans la grille de contr\u00f4le. L\u2019effet Fowler-Nordheim<\/em> implique qu\u2019une partie des \u00e9lectrons qui passent entre les \u00e9lectrodes va se d\u00e9placer vers la grille flottante, \u00e0 travers l\u2019oxyde. Une fois la grille satur\u00e9e avec des \u00e9lectrons, elle devient isolante et est consid\u00e9r\u00e9e comme un 0 binaire. <\/p>\n\n <\/p>\n\n L\u2019effacement d\u2019une cellule s\u2019effectue de la m\u00eame fa\u00e7on, mais en faisant passer une tension n\u00e9gative dans la grille de contr\u00f4le. Les \u00e9lectrons se d\u00e9placent alors de la grille flottante vers le substrat. Une fois la grille flottante \u00ab vid\u00e9e \u00bb de ses \u00e9lectrons, elle est consid\u00e9r\u00e9e comme un 1 binaire.<\/p>\n\n <\/p>\n\n Pour la lecture, c\u2019est assez simple\u00a0: il faut mesurer la r\u00e9sistance de la grille flottante, en faisant passer une tension faible (5 V) dans la grille de contr\u00f4le et dans une des \u00e9lectrodes. Si les \u00e9lectrons passent entre la grille de contr\u00f4le et l\u2019\u00e9lectrode, la grille flottante n\u2019est pas isolante, on a un 1 binaire. Si le courant ne passe pas, on a un 0 binaire. La lecture est donc plus rapide que l\u2019\u00e9criture ou l\u2019effacement, car on ne doit pas remplir ou vider la grille flottante avec des \u00e9lectrons.<\/p>\n\n <\/p>\n\n <\/p>\n\n Notons qu\u2019il existe deux types de NAND, la SLC (Single Layer Cell<\/em>) qui stocke un seul bit dans la grille flottante, et la MLC (Multi Layer Cell<\/em>), qui stocke plusieurs bits dans la m\u00eame cellule. Techniquement, la MLC divise la grille flottante en deux parties, avec une diff\u00e9rence de tension entre les deux parties. On peut donc doubler la capacit\u00e9 de stockage en gardant la m\u00eame taille physique, ce qui est \u00e9videmment avantageux. La m\u00e9moire MLC a cependant des d\u00e9fauts\u00a0: comme on doit travailler avec plusieurs tensions diff\u00e9rentes, l\u2019\u00e9criture et l\u2019effacement des donn\u00e9es sont plus lents qu\u2019avec de la SLC. La lecture reste rapide, mais pas autant qu\u2019avec de la m\u00e9moire SLC (environ 80 % du d\u00e9bit d\u2019une SLC \u00e9quivalente).<\/p>\n\n <\/p>\n\n La m\u00e9moire flash NAND travaille avec un bus s\u00e9rie, en acc\u00e8s s\u00e9quentiel. Il est impossible d\u2019acc\u00e9der directement \u00e0 un bit en particulier, contrairement \u00e0 la m\u00e9moire NOR. Pour acc\u00e9der \u00e0 une information pr\u00e9cise, on doit charger enti\u00e8rement une partie des donn\u00e9es dans une petite m\u00e9moire RAM, et ensuite lire ce que l\u2019on veut dans cette m\u00e9moire.<\/p>\n\n <\/p>\n\n Dans un syst\u00e8me classique (une m\u00e9moire de 16 Go par exemple) on va travailler avec des blocs de 256 ou 512 ko. Le bloc est divis\u00e9 en 64 ou 128 pages de 4 ko. En r\u00e9alit\u00e9, une \u00ab page \u00bb fait plus que 4 ko\u00a0: on a 4 096 octets accessibles, et 128 octets qui servent de contr\u00f4le (gestion ECC, etc.). Les anciens syst\u00e8mes (ou ceux de faible capacit\u00e9) travaillent plut\u00f4t avec des pages de 2 ko avec des 64 octets de gestion et des blocs de 128 ko.<\/p>\n\n <\/p>\n\n <\/p>\n\n Pour ce qui est de l\u2019acc\u00e8s, on travaille en shadowing<\/em>\u00a0: le syst\u00e8me acc\u00e8de en fait \u00e0 une m\u00e9moire RAM qui contient les donn\u00e9es demand\u00e9es. On n\u2019acc\u00e8de jamais directement aux donn\u00e9es stock\u00e9es dans la m\u00e9moire NAND. Le contr\u00f4leur s\u2019occupe de g\u00e9rer la copie de la page dans la m\u00e9moire en question et de la gestion des blocs.<\/p>\n\n <\/p>\n\n <\/p>\n\n L\u2019interface s\u00e9quentielle oblige aussi \u00e0 travailler avec la page comme unit\u00e9 minimale pour la lecture. Si on veut acc\u00e9der \u00e0 un bit pr\u00e9cis, il faut charger enti\u00e8rement une page. Cette particularit\u00e9 explique que la m\u00e9moire flash manque parfois d\u2019efficacit\u00e9 avec les tr\u00e8s petits fichiers\u00a0: la lecture d\u2019un fichier de la taille d\u2019une page (g\u00e9n\u00e9ralement 4 ko) et d\u2019un fichier plus petit prend le m\u00eame temps.<\/p>\n\n <\/p>\n\n Pour l\u2019\u00e9criture, on travaille au niveau du bloc\u00a0: la moindre \u00e9criture oblige \u00e0 effacer enti\u00e8rement le bloc de donn\u00e9es avant d\u2019\u00e9crire une nouvelle valeur. On a donc le m\u00eame probl\u00e8me qu\u2019en lecture, \u00e9crire 1 bit ou \u00e9crire 256 ko (taille typique d\u2019un bloc) n\u00e9cessite le m\u00eame temps au final\u00a0: on doit reprogrammer enti\u00e8rement le bloc. En pratique, l\u2019\u00e9criture de petits fichiers (sous les 256 ko) est donc assez lente avec de la m\u00e9moire flash.<\/p>\n\n <\/p>\n\n Parlons un peu performances\u00a0: du fait de son mode de fonctionnement (s\u00e9quentiel), l\u2019acc\u00e8s aux donn\u00e9es n\u2019est pas instantan\u00e9. Il faut compter environ 25 \u00b5s pour un acc\u00e8s \u00e0 une page (temps de copie dans la RAM interne). L\u2019acc\u00e8s aux autres pages du bloc est plus rapide (environ 0,03 \u00b5s), alors que l\u2019effacement d\u2019un bloc prend environ 2 ms.<\/p>\n\n <\/p>\n\n En comparaison, sur des m\u00e9moires de type NOR, la lecture al\u00e9atoire d\u2019une donn\u00e9e est de 12 \u00b5s (quel que soit l\u2019emplacement de celle-ci) et l\u2019effacement d\u2019un bloc est tr\u00e8s lent\u00a0: 750 ms.<\/p>\n\n <\/p>\n\n Dans les contr\u00f4leurs actuels, une m\u00e9moire cache permet de regrouper en partie les \u00e9critures pour \u00e9viter d’effacer des blocs en masse, m\u00eame si le fonctionnement de cette m\u00e9moire cache varie en fonction des contr\u00f4leurs utilis\u00e9s et que tous les contr\u00f4leurs n’utilisent pas cette technique. <\/p>\n Une des remarques que l\u2019on voit le plus d\u00e8s que l\u2019on parle de la m\u00e9moire flash, c\u2019est sa dur\u00e9e de vie. Nous allons expliquer la raison de cette dur\u00e9e de vie limit\u00e9e, et pourquoi ce n\u2019est pas v\u00e9ritablement un probl\u00e8me actuellement.<\/p>\n\n <\/p>\n\n <\/p>\n\n Il y a deux raisons \u00e0 la dur\u00e9e de vie limit\u00e9e de la m\u00e9moire flash. La premi\u00e8re vient de l\u2019oxyde utilis\u00e9 pour s\u00e9parer les grilles. Comme nous l\u2019avons vu, les \u00e9lectrons doivent traverser cet oxyde pour passer dans la grille flottante ou en sortir. De temps en temps, il peut arriver que des \u00e9lectrons restent captifs de cet oxyde, et soient rel\u00e2ch\u00e9s plus tard, ce qui peut perturber les \u00e9critures et la lecture.<\/p>\n\n <\/p>\n\n La deuxi\u00e8me vient de la structure de la grille flottante elle-m\u00eame\u00a0: avec le temps, les tensions \u00e9lev\u00e9es peuvent l\u2019endommager, ce qui \u00e0 terme va la rendre inutilisable. On consid\u00e8re g\u00e9n\u00e9ralement qu\u2019une cellule de m\u00e9moire SLC peut subir environ 100 000 \u00e9critures avant destruction, et que la m\u00e9moire MLC est moins endurante\u00a0: entre 3 000 et 10 000 cycles d’\u00e9criture, en fonction de la finesse de gravure. Une m\u00e9moire interm\u00e9diaire, la eMLC, atteint 30 000 cycles.<\/p>\n\n <\/p>\n\n <\/p>\n\n La majorit\u00e9 des dispositifs utilisant de la m\u00e9moire flash disposent d\u2019un contr\u00f4leur interne, qui va g\u00e9rer les acc\u00e8s \u00e0 la m\u00e9moire. Il est utilis\u00e9 pour les transferts de donn\u00e9es, mais aussi pour v\u00e9rifier que le dispositif fonctionne bien. <\/p>\n\n <\/p>\n\n <\/p>\n\n Ce contr\u00f4leur v\u00e9rifie automatiquement les \u00e9critures en relisant la derni\u00e8re donn\u00e9e \u00e9crite. S\u2019il lui est impossible de la relire, le bloc complet est d\u00e9termin\u00e9 comme d\u00e9fectueux et l\u2019\u00e9criture est relanc\u00e9e sur un autre bloc. Donc sauf si la m\u00e9moire flash est enti\u00e8rement utilis\u00e9e ou d\u00e9fectueuse, les donn\u00e9es seront \u00e9crites sur le support.<\/p>\n\n <\/p>\n\n La deuxi\u00e8me v\u00e9rification s\u2019effectue aussi durant l\u2019\u00e9criture, avec la correction d\u2019erreurs ECC. Toutes les puces de m\u00e9moire flash disposent de bits de contr\u00f4le, qui servent \u00e0 la v\u00e9rification des donn\u00e9es \u00e9crites. En g\u00e9n\u00e9ral, le contr\u00f4le ECC permet de corriger les erreurs de 1 bit et de d\u00e9tecter les erreurs sur 2 bits. Dans ce deuxi\u00e8me cas, le bloc est indiqu\u00e9 comme d\u00e9fectueux et l\u2019\u00e9criture relanc\u00e9e sur un autre bloc.<\/p>\n\n <\/p>\n\n <\/p>\n\n Une petite explication sur le fonctionnement. On dispose de 3 octets d\u2019ECC par bloc de 512 octets (donc 24 bits). \u00c0 chaque \u00e9criture, le code ECC est calcul\u00e9 et \u00e9crit dans la zone inutilis\u00e9e des blocs de donn\u00e9es. Pendant la relecture, le code ECC des donn\u00e9es est calcul\u00e9 et compar\u00e9 au code ECC de d\u00e9part (celui calcul\u00e9 \u00e0 l\u2019\u00e9criture). Si les deux codes sont identiques, le travail continue. Le premier cas intervient s\u2019il y a une erreur sur 1 bit, \u00e0 ce moment-l\u00e0 c\u2019est corrig\u00e9 et l\u2019\u00e9criture continue. Enfin, il se peut qu\u2019il y ait une erreur de 2 bits, ou une erreur dans le code ECC lui-m\u00eame. Ces deux cas sp\u00e9cifiques ne sont pas corrigibles, et l\u2019\u00e9criture est relanc\u00e9e sur un autre bloc et le bloc est indiqu\u00e9 comme d\u00e9fectueux. La m\u00e9moire r\u00e9serv\u00e9e, dont nous parlons dans les prochaines pages, sert \u00e0 g\u00e9rer ce genre de cas.<\/p>\n Bien \u00e9videmment, les constructeurs se sont pench\u00e9s sur ce probl\u00e8me de la dur\u00e9e de vie, et ils ont impl\u00e9ment\u00e9 plusieurs techniques pour limiter l\u2019usure de la m\u00e9moire NAND, c\u2019est ce qu\u2019on appelle le Wear Leveling<\/em>, ou gestion de l’usure.<\/p>\n\n <\/p>\n\n Dans une cl\u00e9 USB ou un p\u00e9riph\u00e9rique de stockage comme une carte m\u00e9moire le fonctionnement est simple : le contr\u00f4leur va intercepter les \u00e9critures et les distribuer al\u00e9atoirement sur des blocs situ\u00e9s dans l\u2019espace libre. Comme les \u00e9critures ne seront plus concentr\u00e9es sur le m\u00eame bloc physique, on ne risque pas de d\u00e9truire un bloc en particulier si un programme \u00e9crit en permanence sur le m\u00eame fichier. Le probl\u00e8me de cette technique est simple\u00a0: si l\u2019espace libre est trop faible, les \u00e9critures vont se faire fr\u00e9quemment sur les m\u00eames blocs, qui vont s\u2019user et donc devenir inutilisables. <\/p>\n\n <\/p>\n\n <\/p>\n\n La technique utilis\u00e9e est bien plus complexe. Le contr\u00f4leur enregistre le nombre d\u2019\u00e9critures sur chaque bloc, et la derni\u00e8re date d\u2019utilisation de celui-ci. Il est donc capable de d\u00e9terminer la fr\u00e9quence d\u2019utilisation d\u2019un bloc et son usure. Si on doit \u00e9crire une donn\u00e9e, il va d\u2019abord chercher le bloc qui a subi le moins de cycles. S\u2019il est libre, le contr\u00f4leur l\u2019utilise. Par contre, si le bloc contient des donn\u00e9es, il va v\u00e9rifier la derni\u00e8re fois qu\u2019il a \u00e9t\u00e9 \u00e9crit et d\u00e9terminer si c\u2019est une donn\u00e9e statique (pas d\u2019\u00e9criture depuis x temps) ou bien dynamique (le bloc a \u00e9t\u00e9 \u00e9crit r\u00e9cemment).<\/p>\n\n <\/p>\n\n Si c\u2019est une donn\u00e9e statique, il va la d\u00e9placer vers un bloc us\u00e9 et mettre la nouvelle donn\u00e9e \u00e0 sa place. Si c\u2019est une donn\u00e9e dynamique qui se trouve sur le bloc, il va en chercher un autre. L\u2019int\u00e9r\u00eat de la technique consiste \u00e0 placer les donn\u00e9es qui ne sont pas souvent \u00e9crites sur des blocs us\u00e9s et de placer les donn\u00e9es souvent modifi\u00e9es sur des blocs qui ont subi peu d\u2019\u00e9criture. Cette technologie permet de garder une usure constante sur le support, et de ce fait d\u2019augmenter la dur\u00e9e de vie globale.<\/p>\n\n <\/p>\n\n <\/p>\n\n Voici deux graphiques qui montrent l\u2019usure sch\u00e9matique d\u2019un SSD apr\u00e8s un usage simul\u00e9 de quelques mois (le m\u00eame nombre de cycles a \u00e9t\u00e9 effectu\u00e9 dans les deux cas). Ces graphiques sont th\u00e9oriques, mais se rapprochent assez de ce qui se passe en pratique pour \u00eatre int\u00e9ressants \u00e0 analyser.<\/p>\n\n <\/p>\n\n <\/p>\n\n Ce graphique montre un SSD sans protection apr\u00e8s un usage simul\u00e9 de quelques mois. On remarque qu\u2019un certain nombre de blocs ont \u00e9t\u00e9 utilis\u00e9s \u00e9norm\u00e9ment et qu\u2019une grande partie des blocs ont \u00e9t\u00e9 peu \u00e9crits. Des pics d\u2019usures sont pr\u00e9sents, et peuvent potentiellement emp\u00eacher l\u2019usage du support. C\u2019est une estimation, car les constructeurs ne permettent pas de mesurer l\u2019usure d\u2019un support de fa\u00e7on compl\u00e8te : dans le meilleur des cas, on r\u00e9cup\u00e8re l’usure de la cellule la moins us\u00e9e, celle de la cellule plus us\u00e9e et l’usure moyenne.<\/p>\n\n <\/p>\n\n <\/p>\n\n Sur ce graphique, on remarque que l\u2019usure moyenne est un peu plus \u00e9lev\u00e9e, mais qu\u2019il n\u2019y a pas un seul pic d\u2019usure. Comme on \u00e9crit souvent sur un disque, les donn\u00e9es vont tourner sur tout le support, ce qui explique qu\u2019on a une vague \u00e0 la place d\u2019une ligne droite. Si \u00e0 un instant T, une donn\u00e9e statique est sur le bloc le plus us\u00e9, \u00e0 l\u2019instant T+10, ce bloc peut devenir le moins us\u00e9, et donc les donn\u00e9es sont en rotation sur l\u2019enti\u00e8ret\u00e9 du support. On a une moyenne d\u2019utilisation faible, mais pas totalement homog\u00e8ne.<\/p>\n\n <\/p>\n\n <\/p>\n\n Au final, selon les constructeurs, avec les blocs de r\u00e9serve et la technique du Static Wear Leveling<\/em>, la dur\u00e9e de vie des SSD est sup\u00e9rieure \u00e0 celle des disques durs. Point int\u00e9ressant, la dur\u00e9e de vie augmente avec la capacit\u00e9, \u00e9tant donn\u00e9 qu\u2019on dispose de plus de blocs pour distribuer les \u00e9critures.<\/p>\n\n <\/p>\n\n De plus, la majorit\u00e9 des pannes sur les supports de stockage vient en g\u00e9n\u00e9ral d\u2019une d\u00e9faillance m\u00e9canique, et les SSD sont d\u00e9pourvus de pi\u00e8ces en mouvement, ce qui les prot\u00e8ge \u00e9videmment de ce type de panne.<\/p>\n <\/p>\n\n Pour la dur\u00e9e de vie, nous sommes en train d’effectuer quelques tests. M\u00eame s’ils ne sont pas repr\u00e9sentatifs de la r\u00e9alit\u00e9, ils vont servir \u00e0 une chose : d\u00e9finir le comportement d’un SSD quand il est compl\u00e8tement us\u00e9.<\/p>\n\n <\/p>\n\n Dans nos tests, nous \u00e9crivons en boucle sur un SSD bas\u00e9 sur un contr\u00f4leur Indilinx. La m\u00e9moire de ce mod\u00e8le est grav\u00e9e en 43 nm et est en th\u00e9orie capable d’encaisser 10 000 cycles d’\u00e9criture. Pour l’usure, nous avons donc d\u00e9cid\u00e9 de remplir le SSD de 128 Go et de laisser uniquement l’espace n\u00e9cessaire \u00e0 la copie (et la suppression) en boucle d’un fichier de 1 To. <\/p>\n\n <\/p>\n\n Actuellement, le test est en cours depuis environ 3 mois et nous avons \u00e9crit pas loin de 450 To sur le SSD. Pour se donner une id\u00e9e, les constructeurs indiquent qu’un utilisateur moyen \u00e9crit entre 2 et 3 Go de donn\u00e9es par jour, alors qu’un utilisateur \u00ab avanc\u00e9 \u00bb est aux alentours de 10 Go. Dans nos tests, nous \u00e9crivons en moyenne 5 To par jour. <\/p>\n\n <\/p>\n\n Nous vous invitons \u00e0 aller lire les comptes-rendus de notre test, qui sont publi\u00e9s \u00e0 intervalles r\u00e9guliers sur Tom’s Hardware.<\/p>\n\n <\/p>\n\n La m\u00e9moire flash, comme la m\u00e9moire RAM, offre une capacit\u00e9 qui est une puissance de deux. Une puce de 8 \u00ab Go \u00bb offre en fait une capacit\u00e9 r\u00e9elle de 8 Gio, soit 8 589 934 592 octets. Dans les SSD, une partie de cette m\u00e9moire est r\u00e9serv\u00e9e, c’est ce que l’on appelle l’overprovisioning. Cette m\u00e9moire r\u00e9serv\u00e9e sert \u00e0 plusieurs choses : \u00e0 la gestion de l’usure, en cas de probl\u00e8mes quand un bloc est d\u00e9fectueux, etc.<\/p>\n\n <\/p>\n\n <\/p>\n\n Dans un SSD classique, la m\u00e9moire r\u00e9serv\u00e9e est de 7,3 %, c’est la diff\u00e9rence entre la taille annonc\u00e9e en Go (base 10) et en Gio (base 2). Quand une puce offre 8 Go (8 000 000 000 d’octets), elle a une capacit\u00e9 r\u00e9elle de 8 Gio (8 589 934 592 octets). Certains constructeurs jouent plus ou moins sur les mots et il n’est pas rare de trouver des mod\u00e8les de 120 Go qui n’offrent pas r\u00e9ellement 120 000 000 000 octets.<\/p>\n\n <\/p>\n\n <\/p>\n\n <\/p>\n\n Dans le monde professionnel, la r\u00e9servation varie en fonction des mod\u00e8les et des contr\u00f4leurs, mais elle est dans presque tous les cas sup\u00e9rieure aux 7,3 % classiques, dans un souci de dur\u00e9e de vie.<\/p>\n La commande TRIM est une solution \u00e0 la perte de performances induite par le fonctionnement des SSD. Comme nous l’avons vu, la gestion de l’usure implique de devoir chercher une cellule vide ou \u00e0 d\u00e9faut une cellule peu us\u00e9e. Le probl\u00e8me, c’est que le contr\u00f4leur n’est pas capable de d\u00e9terminer directement si une cellule est vide, \u00e9tant donn\u00e9 que les syst\u00e8mes de fichiers n’effacent pas r\u00e9ellement les donn\u00e9es. La solution est simple : impl\u00e9menter un moyen de permettre au contr\u00f4leur de d\u00e9terminer si des donn\u00e9es ont \u00e9t\u00e9 effac\u00e9es.<\/p>\n\n <\/p>\n\n Sit\u00f4t dit, sit\u00f4t fait, tout du moins quand toute la cha\u00eene est compatible. Concr\u00e8tement, la commande TRIM consiste \u00e0 indiquer au SSD que les donn\u00e9es sont effac\u00e9es, contrairement \u00e0 la technique habituelle qui consiste \u00e0 marquer les donn\u00e9es supprim\u00e9es sans les effacer r\u00e9ellement et sans que le SSD puisse le savoir. Avec le TRIM, le SSD est capable de voir o\u00f9 sont les donn\u00e9es effac\u00e9es et donc \u00e9vite de chercher \u00e0 les trouver. L’int\u00e9r\u00eat, c’est que passer la commande est simple : elle ne n\u00e9cessite pas de ressources sp\u00e9cifiques. En effet, c’est un simple indicateur qui va permettre au SSD de mettre \u00e0 jour sa table interne et lui permettre de conna\u00eetre le statut d’une cellule. Il n’y a pas d’effacement physique des donn\u00e9es, le fonctionnement au niveau du syst\u00e8me d’exploitation ne change pas, mais le contr\u00f4leur du SSD sait maintenant si une cellule est effac\u00e9e (logiquement).\u00a0<\/p>\n\n <\/p>\n\n <\/p>\n\n <\/p>\n\n <\/p>\n\n Avant le TRIM, Indilinx proposait une solution interm\u00e9diaire, qui avait l’avantage d’\u00eatre utilisable avec la majorit\u00e9 des Windows, le Wiper. Le Wiper est un petit programme, utilisable sur certains SSD (en fonction du firmware) qui sert en fait \u00e0 synchroniser le SSD et le syst\u00e8me d’exploitation. Cas simple : vous avez un SSD de 32 Go, que vous avez rempli avec votre syst\u00e8me d’exploitation et un fichier provenant d’un DVD que vous avez compress\u00e9. Sans le TRIM, supprimer le fichier est une action que le SSD ne verra pas, pour lui, il est toujours l\u00e0. Le Wiper sert \u00e0 faire correspondre la base du syst\u00e8me de fichier avec la base du SSD, pour lui faire comprendre que le fichier a \u00e9t\u00e9 supprim\u00e9. D\u00e9faut de la technique (outre des bugs sur les Windows 64 bits), il faut lancer le programme p\u00e9riodiquement, ce n’est pas automatique. De plus, le Wiper n’est utilisable qu’en NTFS (une version Linux, en b\u00eata, existe malgr\u00e9 tout). Dans la pratique, c’est plus une solution pour revenir \u00e0 la normale qu’une fa\u00e7on p\u00e9renne de corriger le probl\u00e8me.<\/p>\n Parlons d’un sujet int\u00e9ressant : les \u00ab optimisations \u00bb des SSD. Si certains s’inqui\u00e8tent de la dur\u00e9e de vie et essayent de limiter au maximum les \u00e9critures sur le SSD en d\u00e9pla\u00e7ant le fichier d’\u00e9change ou le cache de certains logiciels sur un autre p\u00e9riph\u00e9rique de stockage, d’autres ne font strictement rien et utilisent un SSD comme un disque dur classique. Dans la pratique, on se situe en fait entre ces deux extr\u00eames.<\/p>\n\n <\/p>\n\n <\/p>\n\n Premi\u00e8re chose \u00e0 faire, passer \u00e0 un syst\u00e8me r\u00e9cent comme Windows 7. En effet, ce dernier est capable de d\u00e9tecter les SSD, tout du moins les mod\u00e8les r\u00e9cents, et il applique quelques optimisations. La premi\u00e8re, c’est la d\u00e9sactivation de la d\u00e9fragmentation automatique, car le fonctionnement intrins\u00e8que des SSD fait que la fragmentation du syst\u00e8me de fichiers n’a pas d’impact r\u00e9el sur les performances. La seconde, c’est l’int\u00e9gration du TRIM au niveau du syst\u00e8me lui-m\u00eame. La troisi\u00e8me, c’est l’alignement des partitions. <\/p>\n\n <\/p>\n\n <\/p>\n\n![\"Image](\"https:\/\/www.tomshardware.fr\/content\/uploads\/sites\/3\/2011\/03\/2x-nm-wafer-edit.jpg\")
<\/a><\/span><\/span><\/span><\/span><\/p>\n\nLa m\u00e9moire flash, comment \u00e7a fonctionne ?<\/h2>\n
<\/a><\/span><\/span><\/span><\/span> (image Wikpedia<\/a>)<\/p>\n\nM\u00e9moire SLC et m\u00e9moire MLC<\/h4>\n\n
<\/a><\/span><\/span><\/span><\/span>Actuellement, on utilise essentiellement de la m\u00e9moire MLC dans les SSD, pour des raisons de co\u00fbt. Et pour des raisons de performances, c’est de la m\u00e9moire qui stocke deux bits par cellule qui est utilis\u00e9e. Des m\u00e9moires \u00e0 trois ou quatre bits existent, mais elles ont le gros d\u00e9faut de diminuer la dur\u00e9e de vie et d’offrir des performances en \u00e9criture tr\u00e8s faible. Les m\u00e9moires 3 bits et 4 bits actuelles se destinent essentiellement aux cartes microSD et aux cl\u00e9s USB d’entr\u00e9e de gamme.<\/p>\nLa flash NAND et l’organisation en blocs<\/h2>\n
<\/a><\/span><\/span><\/span><\/span><\/p>\n\nLecture sur une page, \u00e9criture sur un bloc<\/h4>\n\n
La dur\u00e9e de vie de la m\u00e9moire flash<\/h2>\n
Pourquoi la dur\u00e9e de vie est-elle limit\u00e9e\u00a0?<\/h4>\n\n
Comment rem\u00e9dier au probl\u00e8me\u00a0?<\/h4>\n\n
<\/a><\/span><\/span><\/span><\/span><\/p>\n\n<\/a><\/span><\/span><\/span><\/span><\/p>\n\nLa gestion de l’usure<\/h2>\n
Le Static Wear Leveling<\/h4>\n\n
Une explication en image<\/h4>\n\n
<\/a><\/span><\/span><\/span><\/span><\/p>\n\n<\/a><\/span><\/span><\/span><\/span><\/p>\n\nConclusion sur la dur\u00e9e de vie<\/h4>\n\n
Dur\u00e9e de vie : on est en train de tester<\/h2>\n
<\/a><\/span><\/span><\/p>\n\nLa capacit\u00e9 en question<\/h2>\n
G\u00e9n\u00e9ralement 7,3 %<\/h4>\n\n
SandForce et les professionnels<\/h4>\n\n
<\/a><\/span><\/span>Avec certains contr\u00f4leurs, notamment le SandForce, la m\u00e9moire r\u00e9serv\u00e9e est plus grande. Sur les mod\u00e8les professionnels et les premiers mod\u00e8les grand public, la r\u00e9servation \u00e9tait de 27,2 % environ : ~100 Go effectifs pour 128 Gio r\u00e9els. Sur la seconde g\u00e9n\u00e9ration de mod\u00e8les grands publics, les mod\u00e8les les plus courants, la r\u00e9servation est de seulement 12,6 %, soit environ 120 Go effectifs pour 128 Gio r\u00e9els. Sur certains mod\u00e8les utilisant de la m\u00e9moire en 25 nm, le contr\u00f4leur r\u00e9serve 16,3 %, soit ~115 Go pour 128 Gio r\u00e9els. Nous avons publi\u00e9 un dossier sur l’utilisation de la m\u00e9moire en 25 nm<\/a>.<\/p>\n\nLa gestion du TRIM<\/h2>\n
Un probl\u00e8me dans la cha\u00eene, rien ne va
<\/h4>\n\n<\/a><\/span><\/span>Le principal probl\u00e8me du TRIM, c’est que toute la \u00ab cha\u00eene \u00bb doit supporter la commande. On doit donc avoir un syst\u00e8me d’exploitation qui supporte le TRIM, un pilote de contr\u00f4leur SATA qui accepte la commande et un SSD qui l’interpr\u00e8te. Si pour le premier et le dernier point, c’est assez simple \u2014 tous les SSD r\u00e9cents supportent le TRIM et WIndows 7 aussi \u2014 c’est plus g\u00eanant pour le second. En effet, certains pilotes ne laissent pas passer la commande, ce qui bloque la commande. Si Intel ou tout simplement Microsoft proposent des pilotes compatibles, ce n’est pas n\u00e9cessairement le cas sur d’autres contr\u00f4leurs. De plus, les contr\u00f4leurs RAID ne laissent pas passer la commande TRIM et les syst\u00e8mes \u00e0 base de RAID0 ne peuvent donc pas tirer parti de la commande. <\/p>\n\nLe Wiper, solution interm\u00e9diaire<\/h4>\n\n
Les SSD et les optimisations<\/h2>\n
Passer \u00e0 un OS r\u00e9cent
<\/h4>\n\nAligner les partitions<\/h4>\n\n