Chapitre 5 Persistance

Introduction

Les chapitres précédents nous ont montré l'activité frénétique des processus qui se bousculent pour obtenir le contrôle d'un processeur désespérément séquentiel et de l'espace mémoire qui pour être virtuel n'en est pas moins irrémédiablement fini. De cette activité résulte la construction de structures qui peuvent être grandioses, mais qui resteraient à jamais imperceptibles aux humains si l'ordinateur ne comportait des dispositifs destinés à communiquer avec le monde extérieur : écrans, claviers, haut-parleurs, joysticks, imprimantes etc. Nous ne nous attarderons pas sur le fonctionnement de ces appareils et sur la façon dont le système d'exploitation les actionne, non que ce sujet soit dédaignable, mais parce qu'il est tout compte fait assez peu différent (en plus simple) du fonctionnement des mémoires auxiliaires sur disque magnétique que nous allons examiner maintenant.

5.1 Mémoire auxiliaire

Ces structures magnifiques construites dans l'espace immense de la mémoire virtuelle par des processus qui accomplissent un milliard d'actions par seconde, qu'en reste-t-il lorsque l'on interrompt l'alimentation électrique de l'ordinateur, ou même simplement lorsque le processus se termine ? Rien. La technique employée actuellement pour réaliser la mémoire centrale repose sur des bascules à semi-conducteurs dont l'état dépend de la tension électrique aux bornes, et disparaît sans recours en l'absence de celle-ci. Il n'en a pas toujours été ainsi : jusque dans les années 1970 la technologie de mémoire dominante reposait sur une invention d'An Wang de 1950 et utilisait des tores de ferrite magnétisés. Un courant de commande créait une magnétisation dont l'orientation déterminait la valeur du bit, 0 ou 1. Le champ magnétique subsistait à l'interruption de l'alimentation électrique, ce qui permettait théoriquement de retrouver l'état de la mémoire au redémarrage. Mais cette possibilité était rarement utilisée : la mémoire était petite, les champs magnétiques étaient susceptibles aux perturbations créées par les courants de rupture lors de l'arrêt de la machine, le redémarrage du système d'exploitation comportait des opérations nombreuses qui utilisaient elles-mêmes la mémoire... Bref, si l'on voulait conserver les données et les résultats élaborés par le programme pendant son exécution, et cette conservation apparaissait bien nécessaire, il fallait d'autres dispositifs de mémoire dite auxiliaire, par opposition à la mémoire centrale.

Le type le plus répandu de mémoire auxiliaire est le disque magnétique. D'autres technologies ont vu le jour, mais, comme dans le domaine des processeurs, une technologie s'est développée avec un tel succès que les autres ont été éclipsées, peut-être provisoirement d'ailleurs. La mémoire à bulles magnétiques connaîtra peut-être le renouveau, notamment dans les environnements où la présence de courants électriques n'est pas souhaitable, en conjonction avec les processeurs fluidiques, mais aujourd'hui leurs performances excessivement inférieures à celles obtenues par les moyens classiques les condamnent à l'oubli. Quant aux calculateurs quantiques ou biologiques, ce sont des objets de recherche théorique bien éloignés d'une éventuelle réalisation industrielle.

5.1.1 Structure physique du disque magnétique

Nous n'entrerons pas dans la description détaillée du disque magnétique. Disons seulement ceci. Il comporte généralement plusieurs plateaux circulaires fixés en leur centre sur un axe, comme on peut le voir sur la figure 5.1. Chaque face d'un plateau est recouverte d'une substance magnétisable assez semblable à celle qui revêt la bande d'une cassette de magnétophone. Chaque surface est survolée par une tête de lecture-écriture constituée d'un électro-aimant. Pour écrire, le dispositif de commande envoie dans le bobinage de l'électro-aimant un courant de sens et d'intensité propre à créer un champ magnétique qui va inscrire sur la surface du disque un bit à 0 ou à 1. Pour lire, l'électro-aimant va se laisser traverser par le champ magnétique du bit inscrit sur la surface, ce qui va créer dans son bobinage un courant induit que le dispositif de commande va interpréter comme un 0 ou un 1.

Les bits sont situés sur des pistes concentriques, c'est-à-dire que pendant une opération de lecture ou d'écriture la tête est fixe au-dessus de la surface du disque, jusqu'à la fin du traitement de la piste, puis elle se déplace radialement, par exemple jusqu'à survoler la piste voisine. C'est différent des platines de lecture des disques vinyle : la tête ne touche pas le disque. Et contrairement aux CD-ROMs et aux disques vinyl, il n'y a pas une piste en spirale mais plusieurs, concentriques.

Figure 5.1 : Organisation physique d'un disque

Chaque piste est découpée en secteurs. Une donnée est repérée par son numéro de piste depuis la plus extérieure (appelé numéro de cylindre, parce que l'ensemble des pistes de même rang, situées à la verticale l'une de l'autre, constitue un cylindre), son numéro de plateau (ou de tête de lecture, ce qui revient au même), le numéro du secteur qui la contient et le rang de l'octet dans le secteur. Chaque opération d'accès physique au disque transfère un ou plusieurs secteurs d'un coup, c'est le logiciel (du contrôleur ou du système d'exploitation) qui découpe ou assemble les données à l'intérieur des secteurs.

Les plateaux et les têtes de lecture-écriture sont enfermés dans une enceinte scellée, le HDA (Head-Disk Assembly), mais jusque dans les années 1970 les piles de disques étaient amovibles, ce qui diminuait beaucoup la fiabilité.

Le disque dur est un support de données à accès direct, par opposition à une bande magnétique par exemple qui est un support à accès séquentiel, c'est-à-dire que les blocs de données enregistrés sur une bande sont accessibles les uns après les autres dans l'ordre selon lequel ils ont été écrits ; tandis que sur un disque chaque secteur est accessible individuellement. Le logiciel (en l'occurrence le système) donne au contrôleur un numéro de secteur ou de bloc, le contrôleur place les têtes magnétiques au-dessus du bon cylindre, sélectionne la tête correspondant au bon plateau et attend que le bon secteur passe dessous. Les données sont lues et envoyées au système.

Actuellement tous les contrôleurs présentent au système un adressage linéaire uniforme des secteurs, c'est-à-dire que tous les secteurs sont numérotés en séquence. Le contrôleur fait son affaire de traduire ce numéro d'ordre en numéro de cylindre, numéro de tête de lecture, numéro de secteur. Le contrôleur dispose aussi d'une mémoire tampon (buffer) assez vaste pour regrouper et optimiser les accès physiques.

Un disque de gros ordinateur à la fin des années 1960 pouvait contenir 14 millions de caractères, avec un diamètre de 14 pouces (36 cm) et une dizaine de plateaux, soit à peu près 15 cm de haut. En 2002 les disques récents ont une capacité de 160 milliards de caractères avec un diamètre de 3,5 pouces (9cm) et trois plateaux (2,5 cm d'épaisseur totale). Les temps d'accès moyens ont beaucoup moins progressé, et sont de l'ordre de 8 millisecondes pour un accès aléatoire comportant un déplacement des têtes de lecture et une demi-rotation. Les vitesses de rotation, longtemps de 3 600 tours/minute, atteignent aujourd'hui 10 000 tours par minute. Les débits de transfert atteignent 80 millions de caractères par seconde. En cette année 2002, les prototypes prêts à être commercialisés tournent à 15 000 tours/minute et ont des temps d'accès de l'ordre de 4 millisecondes. Dans ce domaine des performances il convient de noter que les temps d'accès peuvent varier considérablement selon le contexte d'utilisation, et que ces variations sont mises à profit par les publicités de certains vendeurs pour annoncer des chiffres à étudier avec précaution. Ainsi des temps d'accès moyens de 2 ms ne sont possibles que lors d'accès séquentiels où les secteurs d'une même piste sont lus successivement avec des déplacements de tête rares, à la fin de chaque piste, ce qui ne correspond pas à un accès aléatoire.

5.1.2 Visions de la mémoire auxiliaire

Dès l'origine il y a eu deux visions de la mémoire auxiliaire. La première la considère comme une extension moins rapide et de plus grande capacité de la mémoire centrale, avec une propriété supplémentaire : la persistance. Ce serait un peu comme si, après la terminaison d'un processus, le contenu de son espace de mémoire virtuelle était conservé en mémoire auxiliaire de pages pour un usage ultérieur par le même programme ou par un autre. Le processus en se terminant aurait soin de laisser dans cet espace de mémoire des données pertinentes et dont la conservation soit utile.

La seconde vision considère les données persistantes comme foncièrement hétérogènes au contenu de la mémoire centrale. La notion de « fichier », métaphore qui sous-tend cette vision, est celle d'un employé administratif, des services fiscaux par exemple, qui calculerait les impôts d'une population de contribuables : il disposerait en entrée du fichier des personnes imposables, avec une fiche par personne, et par ses calculs il constituerait en sortie un fichier d'avis d'imposition, avec un avis par contribuable. Ce fichier en sortie serait transmis en entrée au service du courrier, lequel après mise sous pli et affranchissement le transmettrait à la poste, etc. On voit que le contenu des fichiers n'a pas grand-chose de commun avec le contenu de la mémoire de l'employé, qui incidemment pour faire son travail a recours à une autre fichier, le volume du Code général des Impôts.

Cette seconde vision introduit donc un type d'objet supplémentaire, le fichier. La naissance de la notion de fichier s'explique historiquement pour deux raisons. Incarner dans un ordinateur réel la vision de la mémoire auxiliaire comme extension de la mémoire centrale butait jusqu'à tout récemment sur des obstacles techniques importants dûs à la difficulté de réaliser des mémoires et des disques de capacité suffisante et de sûreté de fonctionnement assez stable pour y conserver de grands volumes de données. Ensuite, lorsque dans les années 1960 l'informatique a commencé à être utilisée pour la gestion des entreprises et des administrations, elle a rencontré des habitudes de travail où les données étaient justement organisées sous forme de fichiers de cartes perforées traitées par des machines mécanographiques¹, et c'est assez naturellement que la notion de fichier s'est transposée à l'informatique.

D'expérience la notion de fichier n'est pas d'une intuition facile. Les difficultés qui l'accompagnent ne sont pas uniquement pédagogiques, en témoignent le soin que mettent les informaticiens théoriciens à éviter d'en parler et la grande hétérogénéité des errances qui caractérisent ses réalisations techniques.

Considérer la mémoire auxiliaire comme un prolongement persistant de la mémoire centrale, conformément à la première vision évoquée ci-dessus, est beaucoup plus simple à tout point de vue. Qui n'a eu l'occasion, en portant secours à un utilisateur néophyte, de l'entendre parler de son document « en mémoire » sans pouvoir distinguer la mémoire centrale du disque dur ? Dès les années 1960 les auteurs du système Multics avaient choisi de doter leur système d'une mémoire virtuelle de grande taille, dont une partie était constituée de données persistantes sur disque magnétique, chargées en mémoire centrale en tant que de besoin. C'était très élégant et simple, mais la technologie électronique de l'époque condamnait un tel système à la lenteur et à une relative inefficacité, et de surcroît cette solution contrariait les habitudes déjà prises par la corporation des informaticiens.

Au cours des années 1970 sont apparus les systèmes de gestion de bases de données (SGBD), destinés à perfectionner la notion de fichier en dotant une collection de fichiers d'un ensemble de logiciels et d'index qui en permettent une vision et une gestion logiques, globales et cohérentes. L'idée générale est simple : imaginons le système de gestion d'une bibliothèque, autre monde de fichiers. Nous aurons un fichier des auteurs, un fichier des ouvrages, un fichier des éditeurs, un fichier des sujets, etc. Un ouvrage peut avoir plusieurs auteurs, plusieurs éditeurs, plusieurs sujets, mais chaque information n'est enregistrée qu'une fois et les logiciels et les index permettent de retrouver, en balayant les fichiers, tous les livres de tel auteur ou sur tel sujet, sans avoir à écrire un programme spécial à cet effet. L'unicité d'enregistrement de chaque donnée (la non-redondance) concourt à garantir la cohérence de la base.

La commodité apportée par les bases de données dans la gestion des informations persistantes a donné l'idée de créer des systèmes d'exploitation entièrement construits autour d'un SGBD . Ce furent essentiellement le système Pick et la Série 3 d'IBM, dont la postérité a franchi le changement de millénaire sous le nom d'AS/400. Pick, l'oeuvre de Richard Pick, était un système excellent pour la gestion de toutes sortes d'objets, mais la corporation des informaticiens a eu sa peau. Il faut dire que Pick apportait une telle simplification à la gestion que sa généralisation aurait obligé une quantité de programmeurs occupés à des tâches banales et répétitives, désormais réalisables par des non-informaticiens, à trouver un travail plus exigeant.

Aujourd'hui les recherches dans le domaine des systèmes d'exploitation basés sur une mémoire persistante se poursuivent, et nous pensons que leur succès serait la source de progrès notables dans la facilité d'usage des ordinateurs par les humains. Nous y reviendrons.

5.2 Système de fichiers

Puisque tous les systèmes d'exploitation disponibles pratiquement aujourd'hui utilisent des fichiers, nous allons décrire leur organisation. Nous prendrons comme exemple le système de fichiers des systèmes Unix ou Linux, qui à défaut d'une efficacité foudroyante a l'avantage de la simplicité et de l'élégance.

Pour Unix un fichier est une suite de caractères, un point c'est tout. Le programme qui accède au fichier reçoit les caractères les uns après les autres comme un flux, et c'est au programmeur d'avoir prévu les actions nécessaires pour reconnaître dans ce flux des structures de données plus complexes qu'il pourra organiser et traiter.

Les caractères qui constituent ce flux séquentiel qu'est le fichier résident sur disque dur, où ils occupent un certain nombre de pistes elles-mêmes découpées en secteurs (voir la figure 5.1). Un secteur contient généralement 512 caractères. Les secteurs qui constituent un fichier peuvent être physiquement consécutifs sur le disque, mais ce n'est pas forcément le cas. Pour retrouver un fichier, il faut un système de répertoire : chaque fichier possède un nom et le répertoire permet de faire correspondre au nom un emplacement sur le disque (cylindre-piste-secteur), ou plus exactement une collection d'emplacements. Pour éviter un trop grand morcellement les secteurs de 512 octets peuvent être alloués à un fichier par blocs de taille supérieure, en général pas plus de 16 secteurs par bloc, soit 8 192 octets.

5.2.1 Structure du système de fichiers Unix

Notion de système de fichiers

Pour utiliser un disque avec Unix, avant de pouvoir y écrire des fichiers, il faut y installer un ou plusieurs systèmes de fichiers. Ce terme, système de fichiers, désigne à la fois le principe d'organisation des fichiers, les éléments de logiciel qui implémentent (réalisent) ce principe, et un ensemble de fichiers organisés selon ce principe. Dans le cas où plusieurs systèmes de fichiers (au sens : ensemble de fichiers) résident sur le même disque, celui-ci sera partagé en partitions, chacune constituée de cylindres contigus et vue par le système comme si elle était un disque physique. Chaque partition reçoit un système de fichiers. Il existe aujourd'hui pour Unix des systèmes de fichiers (au sens : principe d'organisation et logiciels pour l'incarner) qui permettent à une partition de s'étendre sur plusieurs disques et de changer de taille dynamiquement, mais nous nous en tiendrons ici au système de fichiers classique de Unix, tel ext2 pour Linux². Il faut aussi mentionner le fait que les contrôleurs de disques modernes dissimulent de plus en plus au système la structure physique du disque : ils font leur affaire de la gestion des pistes et des cylindres, qu'ils optimisent, et présentent le disque au système comme une séquence de blocs logiques simplement repérés par leur numéro d'ordre (pour les PCs cette façon de voir les disques se nomme LBA, comme Linear Block Addressing). Pour compléter cet assaut d'abstraction en marche, les Unix modernes comme Linux permettent l'utilisation simultanée de systèmes de fichiers différents, comme par exemple les systèmes VFAT de Windows 98 ou NTFS de Windows 2000 , dont les particularités sont cachées par un système de fichiers virtuel (VFS) qui présente aux autres éléments du système une interface uniforme, manipulée par des commandes identiques que VFS exécute au moyen d'opérations adaptées à chaque système de fichiers particulier, dont le détail est dissimulé à l'utilisateur. On dit que le traitement de ces systèmes de fichiers conformément à leur organisation particulière est pour l'utilisateur rendu « transparent », terme dont on observera qu'en informatique il est synonyme d'opaque.

La i-liste

L'origine de toute information sur le contenu d'un système de fichiers est le super-bloc, qui comporte notamment les données suivantes : taille du système de fichiers, nombre de blocs libres, début de la liste des blocs libres. Comme le super-bloc contient des informations vitales pour la validité du système de fichiers, il est reproduit en plusieurs exemplaires à des emplacements convenus. La structure d'un système de fichiers ext2 est représentée par la figure 5.2.

Figure 5.2 : Structure d'un système de fichiers Ext2 et d'un groupe de blocs

Le super-bloc pointe sur une autre structure de données cruciale, la i-liste (i pour index), qui est en quelque sorte une carte du système de fichiers, permettant d'y retrouver les fichiers. Pour les utilisateurs de tel ou tel autre système d'exploitation, la i-liste correspond à la FAT-table de Windows 98 ou à la MFT de NTFS, le système de fichiers de Windows 2000, ou encore à la VTOC (Volume table of contents) des grands systèmes IBM. Les éléments de la i-liste sont appelés i-noeuds. La i-liste doit refléter à chaque instant la structure logique et le contenu du système de fichiers, et comme celui-ci change à tout moment, au fur et à mesure que des fichiers sont créés, détruits, agrandis ou rétrécis, la i-liste doit posséder une structure très flexible.

Chaque fichier est décrit par un i-noeud, qui doit permettre d'en retrouver tous les fragments, puisque, comme nous l'avons dit plus haut, les blocs qui constituent un fichier ne sont pas forcément contigus, et comment en serait-il autrement d'ailleurs, puisque lorsqu'on agrandit un fichier les blocs qui viennent à la suite ont pu être utilisés entre-temps. Un i-noeud comporte :

douze pointeurs directs, qui donnent l'emplacement sur le disque de douze blocs de données (cas de Linux, pour d'autres Unix ce peut être dix) ;
un pointeur indirect, qui pointe sur un bloc de pointeurs directs, qui eux-mêmes pointent sur des blocs de données ;
un pointeur double indirect, qui pointe sur un bloc de pointeurs indirects, qui eux-mêmes pointent sur des blocs de pointeurs directs, qui eux-mêmes pointent sur des blocs de données ;
un pointeur triple indirect, qui pointe sur un bloc de pointeurs doubles indirects, qui eux-mêmes pointent sur des blocs de pointeurs indirects, qui eux-mêmes pointent sur des blocs de pointeurs directs, qui eux-mêmes pointent sur des blocs de données.

Figure 5.3 : Structure d'i-noeud

Si le fichier tient dans moins de douze blocs (et c'est le cas de la majorité des fichiers), il sera décrit par les pointeurs directs du i-noeud, et les pointeurs indirects ne seront pas utilisés, mais on voit que cette structure géométrique permet de décrire un très grand fichier (voir figure 5.3).

Avec des blocs de 4 kibioctets³ (4 096 octets), chaque pointeur tient sur quatre octets, et nous pouvons avoir :

direct : 12x4Ki = 48 kibioctets ;
indirect : 1024x4Ki = 4 mébioctets ;
double indirect : 1024x1024x4Ki = 4 gibioctets ;
triple indirect : 1024x1024x1024x4Ki = 4 tébioctets.

Outre ces pointeurs qui permettent, à partir du i-noeud, de retrouver les blocs de données, le i-noeud contient aussi d'autres informations capitales, qui sont les attributs du fichier :

les droits d'accès au fichier ;
l'identifiant numérique du propriétaire du fichier ;
sa taille ;
la date du dernier accès au fichier ;
sa date de dernière modification ;
et d'autres...

Le contenu d'un i-noeud peut être consulté par la commande Unix ls.

Le grand avantage de la structure de la i-liste sur d'autres méthodes de gestion, c'est qu'un i-noeud n'a besoin d'être chargé en mémoire que si le fichier qu'il décrit est en cours d'utilisation. Une table linéaire des blocs de disque devrait, a contrario, résider en mémoire de façon permanente, et avec les disques actuels ce serait vraiment encombrant.

Répertoires de fichiers

La i-liste permet de retrouver les fichiers sans ambiguïté par leur numéro de i-noeud, dont l'unicité est garantie, mais ce n'est pas un procédé réellement commode. Les êtres humains préfèrent souvent désigner un fichier (ou un autre objet) par un nom propre qui leur rappelle la nature des données, comme Photo_Tante_Léonie ou fichier_clients_2002. Pour répondre à cette attente, la plupart des systèmes d'exploitation proposent des répertoires (en anglais directories), appelés parfois aussi dossiers (folders) ou catalogues.

De même qu'un répertoire téléphonique permet, pour une personne dont on connaît le nom, de retrouver son numéro de téléphone, un répertoire de fichiers permet pour un fichier de nom connu de retrouver son numéro de i-noeud, qui lui-même permettra d'accéder au fichier. Un répertoire n'est qu'un fichier un peu particulier, dont le contenu est en fait une liste de fichiers, dont certains peuvent d'ailleurs être eux-mêmes des répertoires, appelés pour l'occasion sous-répertoires. Dans la liste figure, pour chaque fichier, son nom et son numéro d'i-noeud, ce qui permet de retrouver commodément le fichier par son nom.

La figure 5.4 donne le format des entrées de répertoire pour un système de fichiers sous Unix (en l'occurrence ici ext2 ou ext3 pour Linux). Les entrées sont de taille variable, ce qui offre l'avantage de permettre des noms de fichiers longs sans pour autant gaspiller trop d'espace disque⁴.

Figure 5.4 : Entrées de répertoire d'un système de fichiers Unix (format classique)

Du point de vue de l'utilisateur, un système de fichiers se présente donc avec une structure d'arbre.

Un arbre est une structure de données définie de la façon (récursive) suivante :

un arbre est soit l'arbre vide soit un noeud ;
un noeud a des fils qui sont des arbres ;
si tous les fils d'un noeud sont l'arbre vide on dit que ce noeud est une feuille ;
outre des fils, chaque noeud comporte une valeur.

Un arbre peut en outre avoir une racine, qui est un noeud situé en haut quand on le dessine, contrairement aux arbres des forêts. Les noeuds qui ne sont pas des feuilles sont parfois appelés « noeuds intérieurs ».

La racine de l'arbre « système de fichiers » est un répertoire tel que tous les fichiers du système de fichiers considérés figurent soit dans ce répertoire racine, soit dans un sous-répertoire du répertoire racine. Les sous-répertoires sont les noeuds intérieurs, et les fichiers ordinaires les feuilles de cet arbre.

Figure 5.5 : Arborescence des répertoires et fichiers Unix

Les figures 5.5 et 5.6 représentent une partie d'un système de fichiers Unix. Un système Unix comporte au moins un système de fichiers, décrit par un répertoire appelé racine (root). Il comporte traditionnellement les sous-répertoires suivants :

etc contient les fichiers de configuration du système et des principaux logiciels ;
bin contient les programmes exécutables fondamentaux ;
local contient les données et programmes généraux propres au système local ;
home contient les répertoires des utilisateurs ;
et d'autres...

Ainsi, le fichier photo_Tante_Léonie.jpg qui appartient à l'utilisateur Marcel P., dont le nom d'utilisateur est marcel, sera répertorié dans le répertoire marcel, lui-même sous-répertoire de home, lui-même sous-répertoire de la racine, à laquelle on ne donne pas de nom. Par convention, le caractère « / » sert à marquer les échelons descendus dans l'arborescence du répertoire : ainsi le fichier photo_Tante_Léonie.jpg a-t-il comme nom complet depuis la racine /home/marcel/photo_Tante_Léonie.jpg. Comme nous n'avons pas donné de nom à la racine, tous les shells s'accordent à la nommer par convention « / ». Le nom complet d'un fichier, qui comporte les noms de tous les répertoires qu'il faut parcourir pour parvenir à lui depuis la racine, est aussi nommé chemin (path).

Outre les sous-répertoires déjà indiqués, le répertoire racine répertorie aussi des fichiers ordinaires (par opposition aux répertoires) tels que /vmunix, le fichier exécutable du noyau, que l'auteur de Linux a baptisé quant à lui /vmlinuz.

Le terme de dossier employé parfois pour désigner les répertoires ne me semble pas très heureux parce qu'il suggère un contenant dans lequel seraient contenus les fichiers, ce qui n'est pas le cas. Un répertoire n'a d'étendue que celle nécessaire à loger ses propres informations sur les fichiers, mais pas les fichiers eux-mêmes, et encore moins les i-noeuds. Il est vrai que la tentation de cette métaphore est omniprésente : lorsque l'on enregistre un répertoire dans un autre répertoire, dont il devient de ce fait un sous-répertoire, tous les fichiers qu'il répertorie apparaissent désormais comme des feuilles de l'arbre de ce répertoire père. Comme, d'expérience commune, la navigation dans une telle arborescence est difficile à faire comprendre aux utilisateurs, l'espoir que la métaphore du dossier rende la chose plus accessible était légitime, même si peu confirmé.

Figure 5.6 : Répertoires et fichiers

Création d'un système de fichiers

On choisit généralement de fractionner l'ensemble de cette arborescence en plusieurs systèmes de fichiers. Ainsi les fichiers des utilisateurs sont-ils généralement répertoriés à partir d'un répertoire /home, qui répertoriera les répertoires personnels des utilisateurs, qui eux à leur tour répertorieront les sous-répertoires et les fichiers personnels. Il est considéré comme de bonne gestion de placer le répertoire /home et tous ses sous-répertoires dans un système de fichiers à part. Ainsi, notamment, lorsque l'on installera dans « / » une nouvelle version du système d'exploitation en effaçant tout l'ancien contenu, les fichiers des utilisateurs ne seront pas affectés. Pour réaliser ceci à partir d'un ordinateur vierge de tout système, on va partir par exemple d'un CD-ROM qui contiendra d'une part les éléments du futur système d'exploitation à installer sur disque dur, d'autre part une version rudimentaire du système pour pouvoir réaliser ce travail, et on procédera ainsi :

On crée avec un programme utilitaire spécial (par exemple fdisk) sur le ou les disques dont on dispose des partitions dont le nombre et la taille sont choisis après lecture de la documentation du système et selon les projets que l'on forme quant à l'utilisation de l'ordinateur. La création d'une partition installe sur le disque un certain nombre de structures de données. Nous prendrons l'exemple d'un disque configuré pour le système de fichiers ext2 sous Linux sur un ordinateur de type PC.
- le premier secteur du disque, nommé Master Boot Record (MBR), contient la table des partitions du disque, repérées par les numéros de leurs secteurs de début et de fin ; une ou plusieurs de ces partitions peuvent être bootables, c'est-à-dire contenir un système d'exploitation susceptible d'être chargé en mémoire ; le MBR contient aussi un petit programme qui permet à l'utilisateur de choisir au démarrage la partition de boot (d'amorçage) ; ce petit programme peut par exemple être LILO, mais il y a des alternatives ;
- chaque partition a pour premier bloc un bloc d'amorçage, afin de pouvoir être bootable ;
- le reste de la partition est divisé en groupes de blocs ; tous les groupes de blocs ont la même longueur et la même structure ; ils contiennent chacun une copie de la structure de données appelée « super-bloc » et une copie des descripteurs de groupes de blocs, qui décrivent la structure de la partition et notamment de la i-liste ; ces copies redondantes permettent de reconstituer la cohérence du système de fichiers contenu par la partition après un dommage physique provoqué, par exemple, par une coupure de courant intempestive ; le programme de réparation de système de fichiers sous Unix est fsck, homologue de SOS Disk bien connu des utilisateurs de Macintosh ;
- fdisk crée aussi la i-liste, destinée à décrire le contenu de la partition.
On affecte une partition à la racine du système « / » et une autre partition à /home ; les partitions peuvent indifféremment être sur le même disque ou sur des disques différents ; il y aura en outre d'autres partitions dont nous ne parlerons pas ici, destinées à d'autres systèmes de fichiers tels que /usr, /local, /tmp, /var... En revanche /bin et /etc restent dans la partition racine parce qu'ils sont indispensables au démarrage du système, y compris pendant la phase où il n'a pas encore accès aux systèmes de fichiers « subordonnés ».
On construit dans chacune de ces partitions un système de fichiers vide avec un programme utilitaire (en général mkfs) ; la création d'un système de fichiers comporte notamment la création de son répertoire racine, qui est une racine « relative » par rapport à la racine « absolue », « / ».
On crée dans « / » un répertoire vide nommé home. Ce répertoire vide sera le point par lequel à partir de « / » on accèdera au système de fichiers home, il est appelé point de montage du système de fichiers home. Cette opération de montage est décrite à l'alinéa suivant.
La procédure de construction du nouveau système d'exploitation va comporter la création d'une table des systèmes de fichiers, le fichier /etc/fstab, qui indiquera que le répertoire à la racine du système de fichiers réservé pour les fichiers des utilisateurs sera raccordé à « / » au point /home : cette opération de raccordement s'appelle le montage d'un système de fichiers. On observera que les notions de système de fichiers et de répertoire sont distinctes bien qu'elles interagissent sans cesse. Le système de fichiers est un objet physique, installé sur une partition. La i-liste décrit physiquement les fichiers situés dans la partition considérée. Le répertoire est une structure logique qui sert à en décrire le contenu du point de vue de l'utilisateur.

5.2.2 Traitement de fichier

Nous avons vu qu'un fichier était une suite de caractères, stockés dans un certain nombre de blocs sur disque ; un i-noeud permet de repérer ces blocs et de les identifier comme parties du fichier ; une entrée de répertoire permet d'associer à ce i-noeud un nom ainsi qu'un chemin d'accès depuis le répertoire racine du système « / ». Par exemple, si je veux conserver des collections de séquences d'ADN, je pourrai donner à mes fichiers des noms qui évoquent l'organisme dont proviennent les séquences qu'il contient : listeria.monocytogenes, arabidopsis.thaliana, xenopus.laevis. Ces noms ne sont-ils pas jolis ? Ils désignent respectivement la bactérie de la listériose, une petite plante commune mais élégante, une grenouille africaine.

Le programmeur qui écrit un programme pour lire ou écrire dans le fichier, de son côté, associe un nom symbolique au flux de caractères en entrée ou en sortie, par exemple séquence.entrée pour le flux de caractères associé à la lecture d'une séquence à traiter.

On peut se représenter le fichier comme une file de caractères, lors de son ouverture un curseur est placé sur le premier caractère, chaque ordre de lecture renvoie le caractère placé sous le curseur et déplace le curseur jusqu'au caractère suivant.

Ouverture de fichier

Comment établir le lien entre un fichier physique, nommé par exemple arabidopsis.thaliana, et le nom symbolique d'un flux dans un programme, par exemple séquence.entrée ? Cette connexion s'appelle assez universellement l'ouverture (open) du fichier. Elle consiste à construire en mémoire une structure de données qui contiendra toutes les informations relatives à l'une et l'autre entité, fichier et flux, ce qui permettra la réalisation effective des entrées-sorties. C'est vite dit, mais l'opération d'ouverture de fichier est assez complexe du fait du grand nombre de types de périphériques et de types de fichiers possibles, ainsi que de la grande variété de méthodes de traitement qui s'y appliquent. Sous Unix, une fois la structure de données construite, elle est ajoutée à une collection de ses semblables, la liste des fichiers ouverts pour le processus courant, liste dans laquelle son numéro d'ordre est appelé descripteur de fichiers.

Le fait de désigner le flux par un nom symbolique qui ne sera associé au fichier physique que lors de l'ouverture permet d'utiliser le même programme pour traiter les fichiers listeria.monocytogenes, arabidopsis.thaliana, xenopus.laevis et bien d'autres.

Une fois le fichier ouvert, il est possible d'exécuter des opérations de lecture ou d'écriture dans le flux correspondant, comme nous l'avons décrit aux sections 3.11.1 et 3.11.2.

5.2.3 Fichiers, programmes, mémoire virtuelle

Parmi les fichiers il en est qui jouent un rôle un peu particulier : ceux qui contiennent des programmes exécutables sous forme binaire. En fait ce sont des fichiers comme les autres, simplement au lieu d'être créés et lus par des programmes ordinaires, ils sont créés par des compilateurs⁵, qui sont en fait des programmes comme les autres, et lus par le système d'exploitation lors du lancement du programme correspondant (voir le chapitre 2, et notamment la section ??, ainsi que la section 3.10). Plus précisément, nous avons vu que c'était l'appel système execve qui devait charger le programme en mémoire et lui fournir des pointeurs sur les éléments de l'environnement établi pour le processus dans le contexte duquel il allait devoir s'exécuter.

Lorsque la mémoire virtuelle a été introduite, par exemple dans les systèmes IBM 370, un programme dont l'exécution démarrait était chargé depuis le fichier où il résidait vers la mémoire virtuelle ; par la suite les pages affectées à ce programme étaient éventuellement évacuées de la mémoire réelle vers la mémoire auxiliaire de pagination. Il y avait là quelque chose d'illogique, qui a été résolu dans les systèmes modernes : le fichier qui correspond au programme possède un format adapté à la pagination, et lorsque le programme est chargé en mémoire virtuelle ce fichier d'origine sert de fichier de pagination aux pages qui lui sont allouées.

5.2.4 Cache de disque

De même que le cache mémoire permet de garder près du processeur les mots de mémoire les plus probablement utilisés dans les instants qui suivent, le système réserve une partie de la mémoire pour y conserver les blocs disque les plus probablement utilisés. Ceci vient s'ajouter au fait que les disques modernes sont dotés de contrôleurs qui comportent également de la mémoire vive qui sert de cache.

Avec un système Unix, la taille du cache de disque s'ajuste dynamiquement à la taille de la zone mémoire disponible. Il n'est pas rare que le cache de disque occupe la moitié de la mémoire réelle à un instant donné. La stratégie est toujours la même : essayer d'avoir en mémoire la page de fichier ou le bloc de disque qui a une forte probabilité d'être bientôt lu ou écrit. Il faut donc trouver de bons prédicteurs des lectures ou écritures prochaines, et cela selon les types d'accès.

Pour le fonctionnement en lecture, le principe « ce qui vient d'être lu sera lu » peut être appliqué. Mais comme souvent les fichiers sont lus séquentiellement, il peut aussi être de bonne politique de charger en mémoire cache (de disque) les blocs de fichier qui suivent celui qui vient d'être lu.

Pour le fonctionnement en écriture, la question est : à quel moment les données contenues dans le cache vont-elles être écrites réellement sur le disque ? Deux politiques sont possibles : lancer simultanément l'écriture dans la mémoire de cache et sur le disque (write-through), ou attendre un moment opportun ultérieur pour recopier le contenu du cache sur le disque (write-back), par exemple lorsque le volume de données à écrire sera jugé optimum, ou lorsque le bus sera libre. La seconde méthode donne de meilleures performances, mais le laps de temps durant lequel les données ne sont qu'en mémoire volatile donne des frissons dans le dos des âmes pusillanimes.

Pour expliquer la différence entre les deux politiques de gestion de cache, risquons une comparaison. Je reçois chaque jour une masse de courrier qui s'empile sur mon bureau : ce sont des résultats d'opérations d'entrée-sortie. La plupart de ces courriers ne me concernent pas directement, mais je dois les conserver dans mes dossiers, pour un éventuel usage futur. J'ai le choix entre deux méthodes :

chaque jour, ouvrir le courrier, repérer pour chaque message de quoi il s'agit afin de déterminer le dossier qui l'accueillera dans mes placards, et ranger chaque document à sa place ainsi choisie : c'est la méthode write-through ;
laisser pendant des mois le courrier non ouvert s'empiler sur mon bureau ; quand l'invasion rend la situation intenable, trois ou quatre fois par an, ranger : c'est la méthode write-back.

Il va sans dire que j'ai recours à la seconde méthode, write-back, bien plus efficace : ainsi quand j'ouvre le courrier, une proportion importante des lettres, notes et autres convocations concerne des événements révolus depuis longtemps, et peut donc aller directement à la corbeille à papiers, sans passer par l'étape fastidieuse et coûteuse du rangement en dossiers. Les adeptes du write-through sont condamnés à devenir de purs bureaucrates à force de prendre au sérieux des messages dont l'expérience prouve que les ignorer purement et simplement ne cause aucun dommage. Et, a priori, j'aurai choisi comme date de rangement un jour tranquille où d'autres obligations plus urgentes ne seront pas différées à cause de cette activité subalterne.

Le rôle de la mémoire persistante est tenu par les dossiers dans les placards ; le plateau de mon bureau joue le rôle de cache. Un long entrainement me permet de savoir assez bien ce que contiennent les piles apparemment anarchiques qui encombrent mon bureau, et je suis capable d'accéder assez vite à un document si le besoin s'en fait sentir, en tout cas beaucoup plus vite que si je dois fouiller dans mes beaux dossiers bien rangés mais dont j'ai oublié depuis longtemps ce que j'y ai mis.

5.3 Systèmes de fichiers en réseau : NFS, SANs et NAS

Pour un centre de calcul d'une certaine importance, il y a trois modèles de solutions possibles pour stocker les bases de données :

disques connectés directement aux serveurs par des attachements IDE ou SCSI ;
disques organisés selon la technologie SAN (Storage Area Network) ;
disques organisés selon la technologie NAS (Network Attached Storage).

Nous allons examiner successivement ces trois solutions. Pour en savoir plus sur SCSI, SAN et NAS on consultera avec profit le livre de W. Curtis Preston[53].

5.3.1 Disques connectés directement aux serveurs

Cette solution est identique à celle qui existe pour les ordinateurs personnels de bureau. Il existe deux techniques de connexion : IDE (Integrated Drive Electronics) et SCSI(Small Computer Systems Interface). IDE est limité à quatre disques, y compris d'éventuels lecteurs ou graveurs de CD-ROM, ce qui ne convient manifestement pas aux configurations envisagées ici, aussi nous limiterons-nous aux interfaces SCSI, non sans avoir signalé quand même qu'IDE a connu des évolutions (ATA comme AT Attachment et SATA comme Serial ATA) qui pourraient un jour en faire des concurrents sérieux de SCSI. Il existe déjà des armoires de disques SATA pour faire des NAS de second niveau bon marché.

La connexion d'un disque SCSI à un ordinateur suppose l'installation dans le fond de panier de l'ordinateur d'une carte contrôleur SCSI qui comporte l'interface adéquate, appelée bus. Il faudra aussi configurer le système d'exploitation pour y inclure les pilotes SCSI adéquats. À un bus SCSI on pourra raccorder, selon les versions, huit ou seize appareils SCSI, disques ou autres (le contrôleur compte pour un), qui seront connectés en chaîne les uns derrière les autres. Retenons que toute raccordement d'une chaîne SCSI à un ordinateur nécessite une intervention avec ouverture du boîtier de la machine. Il s'agit d'une connexion de bas niveau, étroitement couplée à un ordinateur donné.

Figure 5.7 : Chaîne de trois disques SCSI connectée à un ordinateur

5.3.2 Systèmes de fichiers en réseau

Lorsque plusieurs ordinateurs cohabitent sur le même réseau local il est tentant de leur permettre de partager des fichiers. Cette tentation a donné naissance aux systèmes de fichiers en réseau, dont les principaux représentants sont NFS (Network File System) pour les systèmes Unix, SMB (Server Message Block), aussi appelé CIFS (Common Internet File System), pour les systèmes Windows. Citons également le système AppleShare pour les ordinateurs Apple.

Le principe de ces systèmes est toujours le même : le système de fichiers distant est présenté à l'utilisateur comme s'il était local, et celui-ci émet des appels système habituels pour y effectuer des opérations d'entrée-sortie. Le noyau du système intercepte ces appels système et les encapsule dans un message qui va être envoyé au système distant. Le message contient la description de l'opération d'entrée-sortie à effectuer. Il s'agit donc d'un appel de procédure à distance, ou Remote Procedure Call, RPC en abrégé. Le résultat de l'opération est retourné à l'expéditeur par le même procédé.

On conçevra aisément que ce processus, qui consiste à commander l'exécution d'un programme sur un autre ordinateur, est une faille béante de sécurité. Il est donc recommandé de limiter l'usage des systèmes de fichier en réseau à des environnements soigneusement contrôlés. Ces systèmes sont généralement des protocoles sans état, ce qui fait qu'ils ne comportent pas de système de verouillage pour garantir la cohérence des fichiers distants (voir à ce sujet la section 6.6.2). Il est souvent prudent de permettre l'accès à des systèmes de fichiers distants soit à plusieurs utilisateurs, mais uniquement en lecture, soit en lecture et en écriture, mais à un seul utilisateur.

Pour partager des données réparties de façon plus complexe sans encourir les risques que nous venons d'évoquer, il convient d'utiliser pour gérer les données accessibles par le réseau un Système de Gestion de Bases de Données, qui comportera alors les dispositifs désirables de contrôle d'accès.

5.3.3 Architecture SAN

L'architecture SAN est fondamentalement une extension de la technologie SCSI, dont elle reprend les principes tout en en améliorant la réalisation sur les points suivants :

le protocole SCSI a été étendu pour donner deux protocoles plus puissants, Fibre Channel et iSCSI, qui permettent des débits et des longueurs de câbles supérieurs ;
le maximum théorique d'appareils que l'on peu connecter à un SAN en Fibre Channel est de 16 millions ;
plusieurs ordinateurs connectés à un même SAN peuvent accéder concurrement à tous les disques du SAN.

On voit bien le progrès que la technologie SAN apporte en extension et en souplesse de configuration pour de vastes ensembles de serveurs et de support de stockage.

La figure 5.8 montre la topologie d'un SAN de type fabric en Fibre Channel ; il y a deux types de topologies possibles : fabric et arbitrated loop ; la seconde était justifiée par le prix prohibitif des commutateurs de type fabric, mais comme ceux-ci sont devenus plus abordables, la topologie arbitrated loop, moins efficace, ne se justifie plus vraiment et je ne la décrirai pas ici. Lorsque le protocole iSCSI sera sorti de son état actuel de quasi-prototype, il sera possible de construire des SANs à base de commutateurs Ethernet Gigabit, beaucoup plus économiques. En effet, un commutateur 16 ports Fibre Channel de marque Brocade coûte de l'ordre de 20 000 Euros, contre 6 000 Euros pour un commutateur Gigabit Ethernet chez Cisco.

Figure 5.8 : Topologie d'un SAN en Fibre Channel

Les serveurs comportent des HBA (Host Bus Adapters), qui ne sont pas autre chose que des contrôleurs SCSI adaptés au support Fibre Channel.

Contrairement à ce que pourrait suggérer la figure, le commutateur n'affranchit pas les serveurs de la gestion de bas niveau du protocole Fibre Channel (c'est-à-dire en fait SCSI), ils doivent notamment être dotés du matériel et des pilotes adéquats. Le commutateur ne fait qu'aiguiller des flots d'octets vers la bonne destination.

Comme les données sur les disques sont traitées au niveau physique, cela veut dire que les serveurs doivent être dotés de logiciels absolument compatibles, il n'y a aucune abstraction des données.

5.3.4 Architecture NAS

Comme son nom l'indique, un NAS (Network Attached Storage) est un serveur de fichiers (le terme est important) connecté au réseau. Les autres serveurs peuvent accéder au fichiers servis par le NAS au moyen des protocoles de partage de fichiers habituels : NFS (Network File System) pour les systèmes Unix, SMB (Server Message Block), aussi appelé CIFS (Common Internet File System), pour les systèmes Windows.

Figure 5.9 : Topologie d'un NAS

La figure 5.9 représente l'architecture d'un NAS. L'objet appelé « tête du NAS » est en fait un ordinateur équipé d'un système d'exploitation spécialisé qui ne fait que du service de fichiers. En général c'est un système Unix dépouillé de toutes les fonctions inutiles pour le système de fichiers, et spécialement optimisé pour ne faire que cela. Le plus souvent, la façon dont le NAS effectue la gestion de bas niveau de ses disques est... un SAN en Fibre Channel.

Quelle est la différence entre un NAS et un serveur de fichiers ordinaire ? Fonctionnellement, on pourrait répondre : aucune. En fait, tout est dans le système d'exploitation spécialisé. Les protocoles de partage de fichiers mis en oeuvre sur des systèmes ordinaires ont la réputation de performances médiocres et de robustesse problématique. Les NAS de fournisseurs sérieux ont résolu ces difficultés et offrent des performances excellentes.

Quel est l'avantage du NAS par rapport au SAN ? Les serveurs de calcul sont totalement découplés des serveurs de données, il n'est plus nécessaire de les équiper du matériel et des pilotes nécessaires à l'accès physique aux disques, une carte Ethernet Gigabit (quelques dizaines d'Euros) et la pile TCP/IP standard font l'affaire et on ne s'occupe plus de rien. Il est prudent de prévoir un réseau réservé à l'usage du NAS et de ses clients.

Quelles sont les limites de l'architecture NAS ? C'est du service de fichiers, donc les accès de bas niveau ne sont pas disponibles (c'est d'ailleurs le but). Dans l'antiquité, les SGBD utilisaient souvent un mode d'accès aux disques qui court-cicuitait le système de fichiers (raw device), pour des raisons de performances. Aujourd'hui l'amélioration des caractéristiques du matériel a fait que cette approche n'est plus guère utilisée. Les bases de données Oracle de l'Inserm sont installées en mode « système de fichiers ». Les base de données Oracle chez Oracle, Inc. sont installées sur des NAS de la maison Network Appliance.

Quels sont les autres services disponibles avec un NAS ?

mirroring de systèmes de fichiers à distance, par exemple duplication des données de Vilejuif sur le site d'Auteuil ;
gestion du cycle de vie des données : on peut prévoir un stockage de second niveau pour les données inactives mais qu'il faut garder, sur des disques plus lents et moins chers ;
sauvegarde des données autonome, sans intervention des serveurs de calcul : la tête de NAS est un ordinateur, capable de piloter une sauvegarde selon le protocole NDMP (Network Data Management Protocol) supporté par le logiciel de sauvegarde Time Navigator utilisé par l'Inserm.

Dernier avantage : les solutions NAS sont moins onéreuses que les solutions SAN, parce qu'au lieu de mettre de la quincaillerie partout, le matériel destiné au stockage de données est concentré dans une seule armoire (un rack pour les petits NAS comme celui que nous avons à Auteuil).

5.4 Critique des fichiers ; systèmes persistants

Si nous nous remémorons la description du système de mémoire virtuelle donnée au chapitre 4 et que nous la comparions à la description du système de fichiers qui vient d'être donnée, nous ne pouvons manquer d'être frappés par leur redondance mutuelle. L'un et l'autre systèmes ont pour fonction d'assurer la persistance de données qui étaient dans la mémoire centrale pour y subir un traitement, qui cessent d'y résider pour une raison ou une autre, et que l'on souhaite néanmoins conserver pour un usage ultérieur. La différence entre les deux réside finalement dans les circonstances qui dans l'un et l'autre cas amènent les données à cesser de résider en mémoire, et c'est cette différence qui est à l'origine de réalisations techniques dont la ressemblance ne saute pas aux yeux. Mais au fond, la mémoire virtuelle et le système de fichiers font la même chose, avec des différences d'interface plus que de fonctionnement, et l'on peut dire que si la mémoire virtuelle était venue plus tôt les fichiers n'auraient sans doute pas vu le jour.

D'ailleurs, des précurseurs ont choisi de s'en passer. Dans Multics, déjà évoqué à la section 3.10.1, la mémoire virtuelle est découpée en segments de taille variable. C'est une structure de mémoire virtuelle plus complexe que celle que nous avons décrite, mais elle remplit les mêmes fonctions. Eh bien, pour Multics on dit simplement que certains segments sont persistants et résident de façon permanente sur disque. C'est un attribut d'un segment : la persistance ! Et pour savoir quels segments sont présents à tel ou tel emplacement de la mémoire persistante, on utilise une commande de liste des segments, en abrégé ls, que les Unixiens reconnaîtront.

= .9@percent Nous avons déjà mentionné le système Pick et celui de l'IBM AS400, construits autour d'une base de données . Le choix est surtout clair avec Pick : chaque donnée individuelle porte un nom utilisable dans l'ensemble du système, et ce système de nommage est unifié. Par exemple, si le système est utilisé pour une application de paie dans un organisme public, il y a une variable et une seule pour donner la valeur du point d'indice des fonctionnaires. Cette variable a un propriétaire (sans doute le Secrétaire d'État à la Fonction Publique), qui dispose seul du droit d'en modifier la valeur. Tous les programmes qui doivent connaître cette valeur peuvent y accéder. Lors de la parution au Journal Officiel d'une modification de la valeur du point d'indice, une seule opération garantit la justesse de tous les calculs. = .15@percent

Incidemment, cette architecture de données procure aux utilisateurs profanes (et aux autres !) une vision considérablement simplifiée de l'ensemble du processus de traitement et de stockage de l'information. Une grande partie de la complexité de ces choses pour le néophyte tient à la difficulté d'avoir une vision d'ensemble d'un système qui réunit et coordonne des objets qui à l'état actif sont en mémoire et qui au repos sont dispersés dans une foule de fichiers aux statuts variés. Avoir un concept unique de mémoire pour tous les objets, persistants ou non, et une désignation unique pour tout objet quels que soient son état et son activité, ce sont des améliorations intellectuelles considérables. Le corporatisme informatique en a eu raison, provisoirement souhaitons-le.

La recherche sur les systèmes persistants continue, même si elle reste assez confidentielle. L'augmentation des performances des processeurs et des mémoire devrait l'encourager en abolissant les obstacles de cet ordre qui ont eu raison des précurseurs.

Le principe de persistance orthogonale est apparu à la fin des années 1970, dans le domaine des langages de programmation. Il proclame que toute donnée doit être habilitée à persister pendant un délai aussi long qu'il est utile, et que la méthode d'accès à une donnée doit être indépendante de la nature de sa persistance. Dans les systèmes classiques il en va tout autrement : les données volatiles en mémoire centrale sont invoquées par leur nom, les données persistantes sur mémoire externe sont accueillies en mémoire centrale comme le résultat de l'invocation d'une commande d'entrée-sortie. Un système persistant reléguera ces différences techniques dans les couches basses du système et présentera une interface uniforme d'accès aux données.

Les tentatives pour implanter la persistance orthogonale dans les langages ou les bases de données utilisées dans le contexte de systèmes d'exploitation classique comme Unix n'ont pas donné de très bons résultats, parce que le problème de l'accès aux données est trop fondamental pour être résolu de façon totalement différente par un programme d'application d'une part, par son environnement d'autre part. L'auteur de système persistant est amené à gérer la mémoire de manière parfois subtile et complexe, or dans un système classique tel Unix c'est le noyau qui décide des pages de mémoire virtuelle à garder en mémoire volatile ou à reléguer en mémoire auxiliaire, ce qui aboutit à des contradictions.

L'exemple d'un tel échec est fourni par les bases de données à objets qui avaient soulevé un grand intérêt dans les années 1990 avec leur programme très séduisant, qui consistait à stocker les données sous la même forme en mémoire centrale pendant leur vie « active » et en mémoire auxiliaire pendant leur vie « latente ». Le revers de la médaille était que le format des données dans les bases dépendait alors du langage de programmation et du matériel utilisés : une base de données créée par un programme C++ n'était pas accessible à un programme Java, et si elle avait été créée sur une machine Sun à processeur 32 bits elle n'était pas accessible à un programme exécuté par une machine à processeur Alpha 64 bits, sauf à passer par des programmes de conversion de données qui font perdre tout l'avantage attendu. De surcroît la mémoire persistante était réalisée à base de systèmes de fichiers classiques, totalement inadaptés à une telle fonction. Et enfin il résultait de tout ceci une programmation laborieuse et des performances le plus souvent médiocres. Si je puis mentionner mes modestes expériences personnelles de combat avec un Système de Gestion de Données Objet (SGDO ) pourtant réputé très industriel (par opposition aux logiciels libres développés par des chercheurs dans les universités), je ne puis me déprendre d'une impression de bricolage : la trace du système révélait que le SGDO passait le plus clair de son temps à balayer en long, en large et en travers des arborescences de répertoire pour y chercher des données qui étaient tout à fait ailleurs, et à recopier un nombre incalculable de fois la même (grande) portion de fichier en mémoire (au moyen de l'appel système mmap pour les connaisseurs⁶). Il n'y avait bien sûr pour un utilisateur naïf aucun moyen simple d'extraire des données de la base : la seule façon était d'écrire du code C++ bare metal, exercice particulièrement punitif ou pervers. Alors que même si l'on peut reprocher aux Systèmes de Gestion de Bases de Données Relationnelles (SGBDR ) tels que PostgreSQL, Oracle ou Sybase une certaine rigidité, ils offrent au moins une méthode d'accès aux données relativement normalisée et relativement simple avec le langage SQL.

La leçon à en tirer semble être qu'il vaut mieux implanter les fonctions de persistance au niveau du système d'exploitation, quitte à ce que ce soit une couche d'interface ajoutée à un système classique sous-jacent. L'implantation de la persistance dans le système garantit une uniformité de vision pour tous les programmes d'application, évite la redondance de fonctions qui alourdissait tellement les bases de données à objets, bref elle assure la cohérence de la sémantique d'accès aux données. C'était ce que faisait à sa façon Pick, et que fait encore en 2002 le système de l'AS400.

Les principaux projets de recherche en persistance à l'orée des années 2000 sont les suivants :

Le projet MONADS a démarré en 1976 à l'Université Monash (Australie). L'abstraction de base est le segment, à la Multics : persistance à gros grain.
Clouds vient du Georgia Institute of Technology (1988). Les abstractions sont l'objet et l'activité (thread). Repose sur le micro-noyau Ra.
Eumel et ses successeurs L3 et L4 ont leur origine en 1977 à l'Université de Bielefeld, puis au GMD (« Gesellschaft für Mathematik und Datenverarbeitung », équivalent allemand de l'INRIA), et sont principalement l'oeuvre du regretté Jochen Liedtke. Eumel fut le premier système à persistance orthogonale. Il s'agit aussi d'un système à micro-noyau (voir chapitre 10).
Grasshoper est un système à persistance orthogonale développé à l'Université de Saint Andrews, Écosse. Les entités persistantes sont des containers, des loci et des capabilities. Dans les systèmes classiques la notion d'espace--adresse est inextricablement mêlée à celle de processus. Les containers et les loci sont des entités analogues mais mieux distinguées (pardon : orthogonales), qui ont vocation à persister. Le noyau du système lui-même est persistant (il y a quand même toujours une partie non persistante, ne serait-ce que pour le boot).
Charm est le successeur de Grasshoper. Le noyau de Charm n'exporte aucune abstraction pour le support de la persistance, mais uniquement des domaines de protection capable de communiquer avec le noyau.

Charm appartient à une nouvelle tendance parmi les systèmes d'exploitation : au lieu de cacher le matériel derrière des abstractions, il l'expose afin que les stratégies de gestion des ressources soient implémentées en « mode utilisateur ». Cela suppose des dispositions favorables de l'architecture matérielle.

Le motif est de séparer :
- les règles de gestion des ressources de bas niveau ;
- des mécanismes qui les implémentent.
L'auteur du système de haut niveau est libre d'implémenter règles et mécanismes par une bibliothèque.

Incidemment, on peut signaler qu'il existe un système d'exploitation universellement répandu et qui possède beaucoup de caractéristiques « persistantes » : PalmOS, qui anime les ordinateurs de poche PalmPilot et Handspring Visor. Chaque programme reste en mémoire dans l'état où l'utilisateur l'abandonne, et où il peut le retrouver lorsqu'il rallume l'engin. Il n'y a pas de vrai système de fichiers. C'est assez surprenant quand on est habitué aux ordinateurs classiques.

5.4.1 Reprise sur point de contrôle

La notion de reprise sur point de contrôle (checkpoint-restart) est bien sûr au coeur de tous ces systèmes. Le problème à résoudre est le suivant : si un programme est interrompu inopinément en cours de traitement, comment reprendre son exécution sans avoir à la recommencer depuis le début ? Idéalement, il faudrait reprendre au point où l'on s'était arrêté, mais il est raisonnablement acceptable de repartir d'un point en amont pas trop éloigné. La difficulté principale réside bien sûr dans la restauration de ce que nous avons appelé le vecteur d'état du programme : valeur des variables, et contenu des fichiers.

Ce problème n'est pas propre aux systèmes persistants, et il a déjà été abordé et résolu. Dès les années 60 l'OS 360 offrait une possibilité de checkpoint-restart pour les programmes utilisateur. Cette possibilité consistait à enregistrer périodiquement sur disque une copie de la mémoire et un relevé de l'état des fichiers ouverts. En cas d'incident le programme repartait automatiquement du dernier point de contrôle. Ce mécanisme entraînait une consommation d'espace disque considérable pour l'époque et surtout une organisation rigoureuse du lancement et de l'exécution des chaînes de programmes, ce qui en restreignait l'usage.

Aujourd'hui une fonction analogue existe pour les ordinateurs portables : une combinaison de touches de commande permet de sauvegarder le contenu de la mémoire sur disque et de mettre l'ordinateur en veille, puis de le réactiver plus tard, ce qui permet par exemple de changer de batterie sans passer par la procédure d'arrêt du système et de redémarrage, elle-même grosse consommatrice de temps et d'électricité.

Les SGBD convenables offrent la possibilité de déclarer des transactions, c'est-à-dire de déclarer un ensemble d'opérations, par exemple une mise à jour complexe de la base, comme une méta-opération atomique. Conformément à l'étymologie une méta-opération atomique est insécable : soit toutes les opérations de la transaction sont accomplies correctement, soit elles sont toutes annulées. Ceci est destiné à éviter de laisser la base dans un état incohérent, voire inconnu. Les transactions sont généralement associées à un dispositif de roll in-roll out qui permet d'entériner une transaction (roll in) ou de ramener la base de données à l'état antérieur à la transaction (roll out).

Depuis les années 1980 sont apparus sur les systèmes en production, issus de la recherche, les systèmes de fichiers journalisés tels Andrew File System de l'Université Carnegie-Mellon, ADVFS dérivé du précédent dans les laboratoires Digital Equipment (DEC), JFS développé par IBM, XFS réalisé par Silicon Graphics (SGI), et plus récemment sous Linux Ext3fs et Reiserfs. Le principe de la journalisation est le suivant : avant toute opération de modification du système de fichiers par une opération d'entrée-sortie, on enregistre dans un fichier spécial (journal, en anglais log) la description de l'opération, et après l'opération on enregistre qu'elle s'est bien passée. Ainsi, après un incident qui aurait corrompu une partie du système de fichiers, il suffit de « rejouer » les opérations enregistrées dans le journal pour restituer un état cohérent, ce qui est infiniment plus sûr et plus rapide que de recourir à un logiciel de contrôle et de restauration de la cohérence interne du système de fichiers tels fsck sous Unix ou SOS Disk sur Macintosh.

Avec les systèmes persistants, le problème est simplifié autant que généralisé. Un système persistant digne de ce nom n'a ni fichiers ni a fortiori système de fichiers. Il est de ce fait indispensable de garantir à tout prix le maintien de la cohérence du contenu de la mémoire virtuelle, seul lieu de conservation des données, et ce quel que soit l'incident, y compris une coupure de l'alimentation électrique. Les systèmes persistants disposent donc d'un système d'enregistrement de points de contrôle, qui permet de sauvegarder périodiquement le contenu de la mémoire, et de reprise sur incident à partir du dernier point de contrôle. Ce mécanisme n'est pas une option comme dans les environnements classiques, mais un fondement du système. Une conséquence amusante de ce type de fonctionnement, qui surprit les auteurs des premiers systèmes persistants, c'est qu'un programme d'application ne peut pas être informé d'un arrêt du système, puisqu'il est reparti automatiquement comme si de rien n'était.

1: Une erreur historique assez répandue situe l'origine de l'informatique dans la mécanographie. Cette thèse a pris naissance dans l'entourage des grandes entreprises mécanographiques qui se sont converties à l'informatique de gestion, comme IBM et Bull.
2: Les systèmes de fichiers tels que ext2 sont « classiques » au sens où ils diffèrent aussi bien de l'archaïque UFS que des systèmes plus modernes qui permettent la journalisation des opérations (cf. ci-dessous section 5.4.1) et l'extension dynamique de partitions étendues sur plusieurs disques physiques. L'ancêtre commun des systèmes classiques est FFS (Fast File System), créé pour Unix BSD par Marshall Kirk McKusick .
3: Voir note 4.4.6.
4: L'examen des sources du noyau et la lecture des bons auteurs m'a révélé la surprenante diversité des formats de répertoire parmi même différentes versions d'une même variété d'Unix, Linux en l'occurrence. Je donne donc ici un format générique, non pas une référence à utiliser les yeux fermés. Je ne parle ici que des systèmes de fichiers « classiques », parce que les systèmes novateurs comme Reiserfs, XFS et JFS ont abandonné les répertoires à structure de liste linéaire au profit de structures en arbre, à consultation plus rapide.
5: et des programmes cousins appelés éditeurs de liens, destinés à réunir plusieurs programmes simples pour en construire un plus complexe.
6: mmap est un appel système qui réalise la projection d'un fichier en mémoire, c'est-à-dire son chargement intégral, ce qui permet ensuite d'y accéder au prix d'un accès en mémoire. C'est judicieux si l'on doit effectuer de façon intensive des accès à tout le fichier, mais si l'on veut simplement accéder à une donnée c'est un marteau-pilon pour écraser une mouche.