SSD 2009, acte 1 : OCZ Apex et Samsung PB22-J

La fragmentation des SSD

Du point de vue du système, un SSD se comporte exactement comme un disque dur. Le système accède donc aux emplacements d’un SSD comme sur un disque dur, via le système LBA (Logical Block Adressing). Bien entendu, un SSD n’étant pas composé de secteurs, le contrôleur fait la translation entre l’adresse LBA d’un secteur de donnée et la page mémoire flash contenant la donnée.

Au sein d’un SSD neuf, c’est simple, la table de mapping étant linéaire (LBA 0 = Page 0, etc). Toutefois, au fil de l’utilisation, ce mapping peut évoluer, ce pour plusieurs raisons : le wear-levelling tout d’abord, qui est là pour uniformiser l’usure des cellules mémoire, mais aussi des algorithmes d’optimisations de la table de LBA en fonction de l’utilisation – c’est tout du moins ce qu’a mis en avant Intel lors de la détection du problème. En effet, si vous écrivez de petits fichiers de manière aléatoire sur le SSD, ce dernier va regrouper les écritures par bloc afin de les écrire de manière plus séquentielle. Ceci permet d’augmenter les performances en écriture aléatoire et de diminuer l’amplification d’écriture du SSD, mais la table de correspondance LBA/Page évolue de sorte que la prochaine écriture « séquentielle » sera en fait … aléatoire.

Autre problème, chaque puce mémoire est divisée en bloc, eux-mêmes divisés en page. Lors de la lecture, on doit charger une page complète, et lors de l’écriture, on doit écrire un bloc complet. Sur un disque neuf, pas de problème, tous les blocs sont vides et on peut donc écrire dessus. Mais au fur et à mesure de l’utilisation, les blocs vides se font de plus en plus rares, si bien qu’il faudra écrire dans des pages situées dans des blocs partiellement utilisés.

Sachant qu’il n’est donc pas possible d’écrire simplement une page mais un bloc complet, il faudra alors charger les données du bloc en cache, effacer le bloc, puis écrire le bloc entier avec les anciennes et les nouvelles données. Une manipulation qui est donc plus lente qu’une simple écriture !


De fait, il est possible que ceci entraine une baisse des performances du SSD, uniquement en écriture, l’espace libre sur le SSD étant « fragmenté » entre les blocs. Attention, il ne s’agit pas d’une fragmentation classique qu’il est possible de résoudre via un simple outil de défragmentation pour disque dur. Pour y mettre fin, il faut remettre à 0 le SSD, via un utilitaire spécialisé, HDD Erase, ou écrire d’une traite sur l’intégralité du SSD … dans un cas comme dans l’autre, il faut donc faire une croix sur les données contenues sur le SSD !

Nous avions mis en avant ce problème sur le SSD Intel X25-M lors de nos tests. Voici par exemple les débits obtenus en écriture séquentiel sur le disque neuf, puis sur le disque après 30mn d’une session de I/O Meter composée d’écritures aléatoires :


La perte est très importante, du fait de la fragmentation combinée aux "optimisations" au niveau du LBA. Nous avons observé le même phénomène sur le SSD Samsung PB22-J :


Cette fois par contre, l’impact est moindre. Certes, le débit est divisé par plus de deux, puisque l’on passe de 174 à 82 Mo /s, mais ce chiffre est encore très bon. Ceci étant dit, pour chacun des tests, nous fournirons deux résultats pour le SSD Samsung : l’un sur disque « neuf », l’autre sur disque « usé ».

Le test

Pour ce test, nous avons comparé ces nouveaux SSD à différents modèles :

- OCZ Core V2
- Samsung SLC
- Samsung MLC
- Mtron MOBI 3500

L’OCZ Core V2 représente ce qui se fait de « mieux » en combinaison JMicron JMF602/MLC, les SSD Samsung SLC et MLC représentent en quelque sorte les références de la génération précédente, alors que le Mtron MOBI 3500 est une alternative intéressante.

Ont également été rajoutés à titre indicatif les performances d’un VelociRaptor, d’un disque 3"1/2 Samsung SpinPoint F1 640 Go et d’un disque 2"1/2 Samsung SpinPoint M5 160 Go.

Diverses mesures ont été effectuées au cours de ce comparatif. Tout d’abord, nous nous sommes intéressés aux performances « synthétiques » des disques : temps d’accès moyen, débit séquentiel, I/O en accès aléatoire. Viennent ensuite des tests un peu plus applicatifs, à savoir un indice de performance applicatif basé sur PC Mark Vantage et enfin de l’écriture et la lecture de divers ensembles de fichiers. Ces fichiers sont composés de la sorte :

- Gros : 13.2 Go pour 6 fichiers (2.2 Go de moyenne)
- Moyens : 7.96 Go pour 10480 fichiers (796 Ko de moyenne)
- Petits : 2.86 Go pour 68184 fichiers (44 Ko de moyenne)

La source ou la cible lors de la lecture ou de l’écriture sur le disque est un RAID de deux disques Raptor 150 Go. Ce type d’information est bien entendu intéressant puisque si le débit séquentiel donne une idée des performances lors de la copie de gros fichiers, les choses seront différentes avec des petits fichiers.

La machine de test était basée sur un chipset X38 monté sur une carte mère P5E d’ASUSTeK, et les ports Serial ATA étaient configurés dans le bios en AHCI (Advanced Host Controller Interface) afin de disposer du NCQ, le tout fonctionnant sous Vista SP1.