Les SSD des Mac ne seraient, en fait, pas des plus rapides....

Voilà une nouvelle qui risque d’en effrayer plus d’un : Apple aurait « triché » de manière à rendre ses SSD faussement plus rapides par rapport à la concurrence, et ce au détriment de la sûreté des données. Comment se fait-ce ?

Pour comprendre le phénomène, il nous faut plonger dans les entrailles d’un SSD : sans revenir non plus dans les détails de fonctionnement des cellules flash — pour cela, ce Hard du Hard saura tout à fait vous contenter —, sachez qu’un SSD est grosso modo un empilement de zones mémoires semblable à une grosse clef USB. Sauf que ces cellules mémoires sont, d’une part, relativement lentes (comparées à de la DDR par exemple) et possèdent un nombre de cycles de lecture-écriture fixé du fait de leur usure naturelle. Pour contrer ces deux défauts, les fabricants de SSD se sont donc mis à intégrer de la mémoire volatile (typiquement de la DDR3) qui contient temporairement les valeurs à stocker sur le disque, à la manière des caches L1/L2/L3 sur CPU. Sauf que, contrairement au processeur, les données doivent bien être écrites à un moment sur le disque afin de subsister aux arrêts de la machine — prévus ou non.

Pour cela, la commande fsync permet de demander au contrôleur — le « cerveau » du SSD — d’écrire les données présentes dans le cache DRAM sur les cellules, vidant au passage le premier cité. Cela assure notamment que les données soient bien présentes et intègres au redémarrage de votre bousin préféré ou en cas de coupure de courant inopinée. Sauf que, dans le cas des SSD de chez Apple, ce ne serait pas tout à fait le cas : ce fsync ne flusherait qu’une partie des écritures restées dans la RAM système ; et il faudra par la suite demander un F_FULLSYNC pour être certain que les données soient bien présentes sur la partie conservée du SSD.

Or, le comportement Linux des fsync est de demander une écriture complète, d’où des soucis de compatibilité... Vous l’imaginez, en remplaçant les fsync Mac par des F_FULLSYNC, les performances deviennent catastrophiques : il est question de passer de 40 000 IOPS à... 46. À titre de comparaison, une clef USB 3.0 en propose (sans aucun cache, du coup) plus de 200 ! Toutefois, la concurrence n’est pas forcément extrêmement plus reluisante, car un 860 EVO testé dans les mêmes conditions propose, avec son cache, 5 000 IOPS, et seulement 143 en flushant à tout va.

Pour autant, ce design peut se justifier : le M1 sur lequel a été découvert le procédé (également présent sur les Mac T2) est avant tout pensé pour être intégré sur des ordinateurs portables, cas dans lequel le scénario d’une coupure d’urgence de courant est hautement invraisemblable ; d’où le calcul consistant à augmenter les risques de pertes de données dans ce cas-là pour gagner en performances. Il en va de même pour les iPhone, iPad et autres iBidules produits par la firme de Cupertino... mais les Mac Mini et les iMac sont, eux, bien concernés... ouille.

Plus inquiétant encore, Apple ne serait pas le seul a avoir truandé par ce procédé : un autre Twitos du nom de Russ Bishop aurait également testé la chose en débranchant immédiatement 4 SSD après avoir ordonné le fameux fsync : la moitié aurait perdu la mémoire. Largement pas de quoi vous rassurer, surtout si vous habitez dans une région où les coupures du courant sont fréquentes.... cas dans lequel un onduleur sera une sage dépense. Notez qu’un correctif est en théorie possible via une simple mise à jour du firmware, mais rien n’indique aujourd’hui que cela soit effectué dans un futur proche. Méfiance donc !

Un M1 efficace... sur un SSD bidouillé ?