Pourquoi brancher un SSD en USB n’est pas toujours une bonne idée

Je vois de temps en temps des gens qui recommandent d’installer un SSD externe en USB 3.0 pour booster un Mac, plutôt que de perdre son temps à démonter ou de passer en Thunderbolt (nettement plus cher). Mais est-ce vraiment une bonne idée ? Pas toujours, spécialement avec les SSD modernes qui utilisent une mémoire cache dynamique.

Ce que je vais présenter reste un cas assez particulier dans l’absolu, avec un problème assez pernicieux qui n’est pas forcément visible directement. Je vais tenter de l’expliquer et de montrer le (gros) problème. Pour l’exemple, j’ai choisi un adaptateur USB-C vers M.2 (NVMe) et un SSD Crucial P1 de 1 To. Un choix pas anodin, vu que ça met le problème plus en avant qu’avec d’autres SSD.

Les SSD modernes utilisent de la mémoire qui contient trois ou quatre (cas du P1) bits par cellule de mémoire flash. Augmenter la densité permet d’augmenter la capacité et réduire les coûts : si on met quatre bits plutôt que deux ou trois dans la même puce, qui a un coût de fabrication à peu près équivalent, on peut soit proposer plus de capacité pour le même prix, soit diminuer le prix à capacité identique. Le principal problème, c’est qu’augmenter la densité joue sur la durée de vie (ce qui n’est pas réellement un problème avec les capacités actuelles) mais surtout sur les performances. Ecrire quatre bits par cellule, c’est lent, très lent. Sur le Crucial P1, la mémoire dans son état classique ne dépasse pas 80 Mo/s en écriture, une valeur équivalente à celle des SSD d’il y a 10 ans.

Bien évidemment, le P1 (et les SSD de sa génération) écrivent bien plus vite, et Crucial annonce même 1 700 Mo/s (ce qui peut se vérifier en interne ou en Thunderbolt 3). L’astuce ? Les SSD modernes intègrent une mémoire cache pseudo-SLC. En simplifiant, une partie de la mémoire est considérée comme de la mémoire SLC (1 bits par cellule), ce qui augmente drastiquement les performances. Mais ce cache SLC est forcément limité, pour réduire les coûts. Toujours sur le P1 de 1 To, le cache fixe a une capacité de 10 Go environ. Cette valeur ne se réduit normalement jamais. Sur les SSD de plus petite capacité, la valeur diminue assez logiquement (~5 Go sur le P1 de 500 Go). La valeur dépend du constructeur du SSD, de son contrôleur, de sa capacité, etc. Sur un modèle de 1 To qui écrit à 1 700 Mo/s, 10 Go, ça semble peu : on vide le cache en 5 ou 6 secondes. Crucial, comme d’autres, utilise donc un cache dynamique. L’idée est d’utiliser l’espace libre comme mémoire cache SLC, pour garder de bons débits. Sur le P1, toujours, ce cache dynamique atteint ~12 % de l’espace libre (je n’ai pas la valeur exacte). Donc sur un SSD de 1 To vide, on a un cache qui atteint environ 130 Go. C’est nettement mieux.

Point intéressant, ce cache n’est pas nécessairement visible, même dans un test. Les testeurs sérieux connaissent bien le problème, mais le côté dynamique n’est pas nécessairement mis en avant (ou détecté). Et pour un utilisateur lambda, c’est largement invisible. La raison reste simple : les programmes de tests classiques n’écrivent pas assez. Avec un cache qui atteint au moins 5 Go dans la majorité des SSD, on reste dedans dans un test basique. En dehors de quelques logiciels qui permettent de mettre de gros fichiers de cache, on ne peut même pas le voir facilement dans un test synthétique. Un programme comme Blackmagic Disk Speed test se limite à 5 Go, donc on reste largement dans le cache.

Les programmes de tests ne voient pas le problème

Cette façon de faire a tout de même des défauts. Premièrement, si le SSD est rempli, le cache diminue. Sur un SSD avec 500 Go de données, le cache passe à ~80 Go. Si vous avez 750 Go de données, ~45 Go, etc. Deuxièmement, Il s’agit d’un cache dynamique : les données enregistrées comme de la mémoire SLC doivent ensuite être réécrite comme de la mémoire QLC (quatre bits). C’est le contrôleur qui va effectuer ça en arrière-plan, mais ce n’est pas transparent : le SSD consomme et les performances s’en ressentent. En fonction du volume de données, cette réécriture peut prendre un peu de temps.

Maintenant, le problème principal, lié à l’USB. Sous macOS, en USB, le TRIM n’est pas géré. Cette commande permet, en simplifiant, d’indiquer au contrôleur du SSD qu’une donnée à été effacée, pour améliorer la gestion de l’usure. Mais elle intervient aussi dans la gestion du cache : pour gérer le cache dynamique, le SSD doit connaître l’espace libre. Et sans TRIM… il ne peut pas. En pratique, vous ne verrez pas de différence au début : un SSD formaté est considéré comme vide au départ. Mais avec le temps, chaque écriture va s’accumuler et si vous écrivez toutes les cellules… le contrôleur va considérer qu’il est rempli… même s’il ne l’est pas. Imaginons : vous téléchargez une vidéo de 50 Go, vous la regardez, vous l’effacez et vous téléchargez ensuite une seconde vidéo de 50 Go, que vous effacez ensuite. En interne, avec le TRIM, l’espace libre n’a pas bougé. Sans le TRIM, en USB, l’espace libre a diminué de 100 Go. Et une fois que le SSD est considéré comme rempli par le SSD… c’est fini. Après quelques jours ou quelques semaines, donc, vous perdez totalement le cache dynamique.

Petit test

J’ai fait quelques tests pour montrer le problème. En USB-C, le SSD écrit à environ 975 Mo/s dans le cache, et environ 80 Mo/s sans. j’ai commencé par écrire un fichier aléatoire de 200 Go (Gio exactement, je l’explique plus bas). Le SSD a écrit dans le cache pendant 123 secondes (~120 Go), puis sur la mémoire pendant 880 secondes (14 minutes et 40 secondes). J’ai attendu environ 30 minutes pour laisser le temps au cache de se vider et j’ai recommencé. Il y a une marge d’erreur sur mon compteur, sur les valeurs et la montée, mais on voit bien l’ordre de grandeur.

Le cache rapide semble large

Si vous voulez essayer, la commande est la suivante (ça vient de là). Attention, 100g indique 100 Gio et pas 100 Go. Donc pour remplir un SSD de 1 To, il ne faudra que 9 essais (environ).

mkfile -n 100g /Nom/Du/Fichier

Seconde étape, le même test, mais avec un espace libre réduit de 200 Go (le premier fichier). Le cache SLC se vide en 108 secondes (105 Go), ce qui semble assez cohérent. Du coup, le reste prend nettement plus de temps : 17 minutes et 5 secondes (1 025 secondes) pour environ 80 Go de données. Pour vérifier quand le cache dynamique a été vidé, je mesure juste la consommation en USB (avec un petit appareil de mesure) : le SSD tire ~800 mA quand il vide le cache et ~350 mA le reste du temps).

Il rétrécit

Troisième étape, la même. Le cache diminue beaucoup : 42 secondes (donc seulement 40 Go de cache). Le reste prend pas mal de temps : 32 minutes 40 (155 Go).

Encore

Quatrième étape, le cache se vide en 30 secondes (un petit 30 Go). Ensuite, 40 minutes d’écriture.

Et encore

Enfin, j’ai terminé par un fichier de 100 Go. 24 secondes d’écritures dans le cache, le reste directement sur la mémoire (16 minutes 30). Attention, l’image n’est pas la même : le système écrit 100 Go ici et pas 200 Go comme dans les exemples précédents.

Il est très petit

Là, le SSD est rempli (ou presque). Et c’est là que la partie amusante intervient : même en effaçant les fichiers (et donc en libérant de l’espace libre), le cache reste limité à moins de 25 secondes. Pour un usage normal, ça ne pose pas (trop) de soucis mais si vous transférez de temps en temps des données qui prennent de la place, vous le sentez franchement passer.

Bien évidemment, la démonstration force le trait : j’ai pris un adaptateur très rapide et un SSD dont les performances s’effondrent hors du cache. Avec un SSD SATA classique (par exemple un MX500 de la même marque) et un adaptateur USB 3.0 standard, la différence est beaucoup moins grande. Au lieu de passer de 975 Mo/s à 80 Mo/s, on passe par exemple de ~450 Mo/s à un peu moins de 400 Mo/s sur un MX500, de ~450 Mo/s à ~90 Mo/s sur un BX500 (Crucial dans les deux cas), de 2 200 Mo/s à ~600 Mo/s sur un Samsung 970 EVO (nettement plus cher que le Crucial P1) ou de ~500 Mo/s à un peu moins de 200 Mo/s sur un Kingston HyperX Fury. Le comportement dépend fortement du SSD, de son contrôleur et de sa capacité.

Enfin, au passage, je ne parle ici que du cache en écriture, pas de la diminution des performances en cas de surchauffe. C’est un autre problème, même si le résultat pratique reste le même : ça écrit moins vite. Sur le P1, on divise les performances par deux en cas de surchauffe, mais il faut de longues sessions d’écriture pour le faire chauffer assez. Dans une tour bien ventilée ou un boîtier en aluminium, ça n’arrive que très rarement.

Peut-on régler le problème ?

C’est un peu compliqué. Sous macOS, pas réellement. Le formatage n’a aucun impact, la commande TRIM n’est pas envoyée. Vous pouvez brancher le SSD en interne dans un Mac (ou en Thunderbolt) et ça devrait fonctionner, mais ce n’est pas évident. La solution la plus basique consiste à formater le SSD depuis Windows. C’est possible en interne mais aussi dans une machine virtuelle, vu que les adaptateurs USB modernes supportent le TRIM en USB sous Windows (mais pas sous macOS). Mais d’un point de vue pratique, c’est horrible : si le système est sur le SSD, il faut tout effacer et tout réécrire, ce qui fait perdre une partie de l’intérêt de la remise à zéro. En réalité, tant qu’Apple ne se décide pas à supporter le TRIM en USB, le problème restera présent.

En pratique, si vous voulez utiliser un SSD externe en USB, spécialement pour démarrer dessus, je vous recommande de vous diriger vers un SSD qui n’utilise pas de cache SLC ou qui – à défaut – garde des performances correctes. Chez Crucial, il s’agit du MX500 (en SATA), chez Samsung, les 860 EVO ou Pro restent efficaces. En réalité, évitez les modèles d’entrée de gamme (BX500 chez Crucial par exemple) ou ceux à base de mémoire QLC (Samsung 860 QVO, Crucial P1, Intel 660p, etc.) pour cet usage précis.