Le M4 et l’over-provisioning

Aussi curieux que cela puisse paraitre, les SSD de Crucial avec contrôleur Marvell font l’impasse sur l’over-provisioning. L’utilisateur récupère ainsi un peu plus d’espace utile par rapport aux produits concurrents, mais les performances pourraient bien en pâtir.

Over-provisioning, garbage collection et performances

Rappelons que l’over-provisioning correspond à l’espace mémoire réservé en cas de problème (gestion de l’usure, blocs défectueux …) mais aussi à la tenue des registres du SSD. Au fur et à mesure de son utilisation, les blocs mémoire diffus sont récupérés pour optimiser les opérations en écriture : c’est ce qu’on appelle le processus de garbage collection.

Concrètement, l’absence totale d’over-provisioning pourrait bien handicaper le M4 plus son espace est proche d’être intégralement utilisé. Nous avons donc copié des répertoires entiers depuis notre SSD système jusqu’à ce que le M4 soit plein vu qu’il s’agit potentiellement de la pire des situations.

Comme prévu, les performances se dégradent lorsque le SSD est plein. Nous avons ensuite laissé le M4 pendant une demi-heure en idle le temps que le processus de garbage collection fasse effet : on revient alors à un niveau de performances satisfaisant, mais pas aussi bon qu’à la première utilisation. En y regardant de plus près ce sont surtout les débits en lecture qui souffrent.

L’Intel SSD 510 ne perd qu’environ 8,5 % de ses performances en lecture et récupère celles en écriture. En comparaison, le M4 abandonne 40 % en lecture. Le constat est meilleur en écriture mais on voit tout de même que les performances ne cessent de fluctuer, signe que le processus de garbage collection est clairement plus efficace chez Intel : les débits du SSD 510 sont non seulement plus élevés mais aussi plus réguliers.

Un autre test intéressant consiste à observer à quelle vitesse les blocs sont rendus disponibles et donc évaluer l’efficacité de la commande TRIM. Rappelons que cette dernière ne supprime pas les données comme c’est le cas lors d’un effacement sécurisé, mais fait savoir au contrôleur que l’Os n’utilise plus un espace de stockage déterminé. Il faut donc effacer un bloc pour le rendre à nouveau disponible en écriture et c’est là que l’on arrive à un paradoxe : un bloc ne peut pas être effacé lors qu’il est pris individuellement, mais comme partie d’un groupe de blocs. Une fois un SSD rempli et après avoir exécuté la commande TRIM, c’est donc l’aptitude du contrôleur à « recycler » les blocs qui détermine les performances en écriture.

On peut y arriver après avoir rempli puis vidé le SSD à nouveau, le vidage de la corbeille étant l’action qui déclenche la commande TRIM. Si les performances en écriture séquentielle sont inférieures après TRIM à celles que l’on observe à la première utilisation, c’est qu’il y a un goulet d’étranglement au niveau du processus de recyclage.

On constate effectivement que les performances post-TRIM n’atteignent pas celles que l’on observe suite à un effacement sécurisé, même si la perte est minime (3 %). Ce n’est donc pas au niveau du processus de garbage collection que l’absence d’over-provisining peut jouer des tours au M4.