La malédiction des fichiers
Au début des ordinateurs était la mémoire. Comme sa capacité était trop limitée, par héritage de la mécanographie, on a inventé le fichier. Ces deux catégories de mémoire obéissent à des principes de gestion complètement différents, appliqués par des parties distinctes du système d’exploitation. Les méthodes de programmation pour accéder à l’une ou à l’autre sont totalement différentes. J’ai formulé ailleurs la critique de cette différence, source de perplexités insondables pour les profanes, qui pour une fois ont bien raison.
Ne serait-il pas plus élégant d’en rester à une forme unique de mémoire, organisée de telle sorte que certaines de ses régions soient persistantes (ce qui est en principe la justification des fichiers) ? Ainsi (c’est Christian Queinnec qui m’en a donné la formule) il y aurait dans la mémoire des objets, dont certains seraient dotés de l’attribut « persistant », ce qui voudrait dire qu’avant l’extinction du processus qui les a créés, ils seraient munis d’un nom unique, et déplacés dans une région persistante de la mémoire (un disque par exemple). Il y a déjà longtemps, c’est ainsi que Multics envisageait les choses. Des systèmes plus récents en ont repris l’idée.
La nature physique des dispositifs utilisés pour enregistrer les fichiers, disques durs et bandes magnétiques essentiellement, nécessitait des méthodes d’accès spécifiques. Mais l’évolution technologique ne pourrait-elle pas nous délivrer des fichiers ?
Les SSD, un progrès décisif
Bien que l’idée soit ancienne, c’est depuis une dizaine d’années que les progrès de l’électronique ont permis l’apparition et le développement rapide des Solid-State Devices (SSD), c’est-à-dire d’unités de stockage qui utilisent comme support non plus des disques magnétiques en mouvement rotatif, mais des circuits électroniques intégrés, comme des clés USB mais plus grosses et avec un accès plus rapide. Les premiers modèles avaient une faible capacité et un coût élevé, mais aujourd’hui la convergence avec les disques durs traditionnels est telle que l’on peut prévoir la disparition de ces derniers dans quelques années. Actuellement, à volume égal un SSD est 10 à 30 fois plus cher qu’un disque dur et 10 fois plus rapide. Les disques durs ont encore quelques arguments techniques en leur faveur, mais pas pour longtemps. Les SSD sont moins fragiles parce qu’ils n’ont pas de pièces mobiles, plus légers, ils consomment moins d’électricité.
Voici le schéma d’un disque dur :
Pour des raisons de compatibilité avec les connectiques et les systèmes d’exploitation existants, la plupart des SSD utilisent des méthodes d’accès et des interfaces analogues à celles des disques durs. Mais c’est en train de changer, et ce changement qui n’attire guère l’attention pourrait avoir de grandes conséquences sur l’informatique en général.
NVMe : espoir d’être enfin débarrassé des fichiers ?
À la section précédente j’écrivais que les SSD étaient interfacés au système comme des disques durs, ce qui permettait de ne rien changer à l’architecture des ordinateurs et au système d’exploitation. Mais cette façon de faire ne permet pas d’exploiter toutes les qualités nouvelles des SSD.
En effet, un disque dur est un matériel mécanique en rotation (15 000 tours/minute pour les modèles récents, 3 600 pour les modèles simples). L’accès à une donnée se décompose en trois temps : le délai de déplacement radial du bras qui porte les têtes de lecture afin de le placer au-dessus de la piste voulue (temps de seek, merci Nat pour la mise au point), le délai rotationnel pour que le secteur qui contient la donnée arrive sous la tête de lecture (en moyenne le temps d’un demi-tour de piste, soit de 2 à 30 millisecondes selon les modèles), et le temps de lecture proprement dit, de l’ordre de la milliseconde. En outre, avec un tel mécanisme on ne peut lire ou écrire qu’un secteur à la fois par surface, et lire à la fois sur plusieurs plateaux est une gymnastique en général impossible parce qu’elle demanderait des synchronisations complexes (cf. ci-dessous les messages du forum, avec des précisions apportées par de fidèles lecteurs-contributeurs).
Assujettir le pilotage des SSD aux contraintes des disques durs était simple dans un premier temps, mais finalement contre-productif. En effet, l’accès aux données d’un SSD se fait à peu de choses près comme un accès à la mémoire centrale de von Neumann : accès direct à n’importe quelle position, possibilité d’accès simultané à plusieurs données.
Afin de tirer meilleur parti des caractéristiques des SSD, un consortium qui regroupe pratiquement tous les acteurs du domaine (constructeurs et éditeurs de systèmes d’exploitation) a élaboré à partir de 2011 une nouvelle norme d’interface, NVMe (pour Non-Volatile Memory express). NVMe affranchit l’accès aux données persistantes des contraintes mécaniques liées aux disques durs, et se rapproche des méthodes de gestion, d’adressage et d’accès de la mémoire centrale (toujours au sens de von Neumann).
Cette évolution ouvre enfin la voie à la suppression des fichiers, que j’appelle de mes vœux comme exposé dans un article précédent. En effet, le fichier, qui ne parvient guère au statut de concept, est un des principaux obstacles à la compréhension de l’informatique par les néophytes, et la réunification de la mémoire centrale et de la mémoire persistante en un concept unique, avec un mode d’adressage unique, serait un progrès considérable, tant pour les auteurs de logiciels que pour l’initiation des utilisateurs. Quand on pense à toute la gymnastique compliquée qu’il faut apprendre pour lire et écrire des fichiers, on ne peut que souhaiter en être bientôt débarrassé !
Expérience concrète avec NVMe
Depuis l’écriture des premières sections de cet article j’ai acquis un ordinateur portable Acer Swift SF514-54T équipé d’un « disque » NVMe : je dois dire que les performances semblent incomparables avec celles de l’Asus avec SSD SATA que je possédais auparavant, mais comme ce dernier a rendu l’âme, je n’ai pas pu faire de vrai banc d’essai comparatif.
Quels sont les procédés qui ont permis cette accélération des transferts de données ? Nous en trouvons quelques explications dans l’article de Techtarget NVMe SSDs : Is there a need for all this speed ?. Le protocole NVMe a été conçu en s’affranchissant de toutes les contraintes imposées par les disques mécaniques, et qui affectaient les protocoles SATA et SAS (ainsi que son ancêtre SCSI). À l’époque où furent conçus ces protocoles, l’accès à la mémoire centrale était 1 million de fois plus rapide que l’accès aux disques, qui se mesurait en milisecondes. Et les caractéristiques de ces matériels ne permettait pas la parallélisation des accès, ou alors au moyen de gymnastiques combinées du matériel et du logiciel, complexes et aux résultats incertains. Les mémoires SSD, constituées de multiples composants électroniques disposés sur une carte, se prêtent par contre bien aux accès en parallèle.
Les disques mécaniques, lents, ne pouvaient pas être connectés directement au bus système, il leur fallait un contrôleur, en fait un calculateur spécialisé qui recevait les demandes d’accès et les traitait selon ses propres méthodes. Les SSD sont suffisamment rapides (temps d’accès de l’ordre de 10 microsecondes) pour être connectés directement au bus PCIe, côté Northbridge, cependant que les commandes passent directement par une interface par registres. Les opérations peuvent être regroupées, compilées et optimisées (streamlined), ce qui réduit la charge du processeur (et la dissipation thermique).
La rapidité des réseaux modernes, type Infiniband, permet l’utilisation de NVMe pour des systèmes de stockage externes, avec recours à Remote Direct Memory Access (RDMA). On voit que c’est toute la problématique du stockage de données qui est bouleversée.
Un autre article de Techtarget NVMe speeds explained donne ce tableau comparatif avec les méthodes SATA et SAS, conçues pour les disques mécaniques :
Interface | IOPS | Débit | Latence | Files | Commandes |
---|---|---|---|---|---|
d’attente | par file | ||||
SATA | 60 000 à | 6 Gops | 1 à 100 ms | 1 | 32 |
100 000 | |||||
SAS | 200 000 à | 12 Gops | 0,1 à 100 ms | 1 | 256 |
400 000 | |||||
NVMe | 200 000 à | 32 Gops | 10 à 225 µs | 65 535 | 64 000 |
10 000 000 |