Systèmes de fichiers

Un fichier est une séquence persistante d’octets. Le système de fichiers stocke ces octets sans décider s’ils représentent du texte, une image ou du code machine. Un répertoire donne au fichier un nom lisible ; son numéro d’inode l’identifie au sein du système de fichiers.

Ouvre un fichier et vérifie le résultat

open(path, flags, mode) renvoie un descripteur de fichier, un entier positif ou nul utilisé dans les appels ultérieurs. En cas d’erreur, l’appel renvoie -1 et définit errno. Choisis O_RDONLY, O_WRONLY ou O_RDWR pour l’accès. O_CREAT crée un fichier manquant, O_TRUNC vide un fichier existant et O_APPEND place chaque écriture à la fin actuelle.

Pour un nouveau fichier, mode demande des permissions et l’umask du processus en retire certains bits. Sans liste de contrôle d’accès (ACL) par défaut sur le répertoire, le résultat est mode & ~umask. Demander 0666 avec l’umask 0022 donne 0644, soit rw-r--r--. Cet argument ne modifie pas les permissions d’un fichier déjà existant.

Les descripteurs appartiennent à un processus. Normalement, 0, 1 et 2 correspondent à l’entrée standard, à la sortie standard et à la sortie d’erreur standard. open choisit le plus petit descripteur inutilisé, souvent 3. Sous Linux, strace cat notes.txt montre les appels : ouverture de l’entrée, lecture, écriture vers le descripteur 1, puis fermeture de l’entrée.

Suis le déplacement, pas le nombre demandé

read(fd, buf, n) renvoie le nombre d’octets effectivement lus, jusqu’à n. Pour une demande non nulle sur un fichier ordinaire, zéro signifie qu’il ne reste aucun octet à lire à la fin du fichier ou au-delà ; -1 indique une erreur. write renvoie aussi un nombre effectif, qui peut être inférieur au nombre demandé. Vérifie ce nombre avant d’avancer dans un tampon ou de décider que l’opération est terminée.

Supposons que log.txt contienne 300 octets. Quatre demandes de 100 octets renvoient 100, 100, 100 et 0. Le déplacement, soit la position de la prochaine opération, devient respectivement 100, 200, 300 et 300. La fin de fichier se traduit par un nombre renvoyé, pas par un octet spécial stocké dans le fichier.

lseek(fd, 200, SEEK_SET) fixe le déplacement à 200. La lecture de 50 octets renvoie alors les octets 200 à 249 et laisse le déplacement à 250. SEEK_CUR compte depuis le déplacement courant ; SEEK_END compte depuis la fin du fichier. Modifier le déplacement change un nombre en mémoire. Cela ne déplace pas une tête de disque et ne lit pas de données en soi. pread et pwrite utilisent une position explicite sans modifier ce déplacement.

Détermine quels descripteurs partagent un déplacement

La table des descripteurs du processus pointe vers des entrées de la table des fichiers ouverts du noyau. Chaque entrée de fichier ouvert contient le mode d’accès, le déplacement, une référence à l’inode et un compteur de références.

Si un fils place un descripteur partagé à l’octet 10, la prochaine lecture du père par cette entrée commence elle aussi à 10. L’inode identifie le fichier, mais l’entrée de fichier ouvert contient le déplacement : deux lecteurs peuvent partager un fichier sans partager leur position. La redirection de l’interpréteur de commandes utilise dup2 pour faire référence à une autre entrée de fichier ouvert depuis la sortie standard. close libère un descripteur ; l’entrée disparaît après la libération de sa dernière référence. La fermeture seule ne force pas l’écriture des données en tampon sur un stockage stable.

Une écriture réussie et une mise à jour qui résiste aux pannes répondent à des questions différentes. Une écriture indique que des octets ont été acceptés. La durabilité concerne leur survie à une panne ; l’atomicité concerne la possibilité de n’observer une mise à jour que dans son ensemble.

Force l’écriture des octets sur un stockage stable

Les systèmes d’exploitation mettent généralement les écritures en tampon en mémoire et envoient les blocs modifiés au stockage plus tard, souvent dans un délai d’environ 5 à 30 secondes. Cela regroupe les petites écritures et permet au programme de continuer rapidement. Une panne peut effacer les données qui attendent encore dans ces tampons.

fsync(fd) force l’écriture des données et métadonnées modifiées du fichier sur le stockage et attend que le périphérique signale la fin de l’opération. Un programme doit vérifier son résultat avant de déclarer l’enregistrement durable. close libère le descripteur et ne remplace pas cette attente.

Un fichier a aussi besoin d’un nom durable. L’entrée qui associe le nom à l’inode est une donnée appartenant à son répertoire, pas au fichier. Après la création d’un fichier, synchroniser uniquement le fichier peut rendre ses octets durables sans garantir la survie de son nouveau nom. Ouvre le répertoire qui le contient et synchronise-le lorsque le nom doit persister.

Remplace un fichier sans exposer de version partielle

Écraser un document sur place crée une période pendant laquelle les lecteurs peuvent rencontrer un contenu incomplet. O_TRUNC ramène d’abord sa longueur à zéro. Si une panne interrompt les écritures ultérieures, l’ancienne copie complète a déjà disparu.

Écris plutôt le contenu de remplacement sous un nom temporaire dans le même répertoire. Utilise ensuite rename pour remplacer la destination. Pour une destination existante sur le même système de fichiers, POSIX rend ce remplacement atomique : le nom de destination désigne l’ancien fichier ou le fichier de remplacement, sans absence intermédiaire du nom. Les lecteurs ne voient pas de mélange de leurs contenus par ce nom.

Pour settings.json, la séquence de remplacement durable est la suivante :

1. Écris tout le nouveau contenu dans settings.json.tmp, en vérifiant les écritures partielles et les erreurs.
2. Appelle fsync sur le fichier temporaire et vérifie sa réussite.
3. Appelle rename("settings.json.tmp", "settings.json") et vérifie sa réussite.
4. Appelle fsync sur le répertoire contenant le fichier et vérifie sa réussite.

Le fichier temporaire est complet et durable avant le changement de nom. La synchronisation finale du répertoire rend ce changement de nom durable. Une panne pendant la séquence laisse à la destination une ancienne version complète ou une nouvelle version complète ; après la réussite de la synchronisation finale, la nouvelle version est durable. Le seul remplacement atomique du nom ne garantit pas qu’un renommage non synchronisé survive à une coupure de courant.

rename échoue avec EXDEV entre systèmes de fichiers. Une commande qui réagit en copiant puis en supprimant effectue plusieurs opérations : cette solution de repli ne garantit donc pas un remplacement atomique.

Modifie la longueur sans écrire chaque octet

truncate(path, length) et ftruncate(fd, length) définissent la longueur du fichier. La réduire élimine les octets situés après la nouvelle fin. L’augmenter fait lire la nouvelle zone comme des zéros. Se déplacer au-delà de la fin puis écrire crée aussi un vide lu comme des zéros.

Un fichier creux peut représenter un tel vide sans lui allouer de blocs de données. À partir d’un fichier vide, écrire un octet au déplacement 8 192 crée un fichier de 8 193 octets ; la zone précédente non écrite est lue comme des zéros. Sa taille logique peut dépasser l’espace qui lui est physiquement alloué.

Les répertoires séparent les noms utilisés par les personnes des objets stockés par le système de fichiers. Chaque répertoire possède son propre inode et ses blocs de données ; ses entrées associent des noms à des numéros d’inode.

Suis les chemins dans l’arborescence

Un chemin absolu part de /. Un chemin relatif part du répertoire de travail courant du processus. L’entrée . désigne le répertoire lui-même et .. désigne son parent ; le parent de la racine est la racine. Depuis /home/lee, le chemin relatif ../shared mène à /home/shared.

Une extension comme .txt fait partie d’un nom. Les programmes peuvent l’utiliser pour choisir comment interpréter les octets, mais le système de fichiers n’impose pas qu’un fichier .txt contienne du texte.

mkdir crée un répertoire contenant . et ... Pour lister les entrées, un programme utilise opendir, appelle readdir jusqu’à ce qu’il ne reste plus d’entrées, puis appelle closedir. Un résultat de readdir comprend un nom et un numéro d’inode. Les programmes modifient le contenu des répertoires au moyen d’appels comme link, unlink et rename, et non d’appels ordinaires à write. rmdir supprime un répertoire vide.

Donne deux noms équivalents à un fichier

link(old, new) crée un lien physique : une autre entrée de répertoire pointant vers le même inode. Aucun des deux noms n’est privilégié comme original. Le nombre de liens de l’inode indique combien de noms le désignent.

Considère ces commandes lorsqu’aucun processus ne garde le fichier ouvert :

echo hi > a
ln a b
rm a
cat b
rm b

La création de b fait passer le nombre de liens de 1 à 2. La suppression de a le ramène à 1 ; b donne toujours accès aux mêmes octets, donc cat b affiche « hi ». La suppression de b ramène le nombre à 0, ce qui permet de récupérer l’inode et ses blocs.

Un descripteur ouvert ajoute une seconde règle de durée de vie. Si le dernier nom est supprimé alors qu’un processus a encore le fichier ouvert, ce processus peut continuer à y accéder. La récupération attend à la fois que le nombre de liens soit nul et qu’il n’y ait plus de référence ouverte. Cela explique pourquoi la suppression d’un grand fichier journal ouvert peut ne pas libérer immédiatement son espace.

Un lien physique ne peut pas traverser les systèmes de fichiers : le numéro d’inode de la destination n’aurait pas de sens dans l’autre table des inodes. La plupart des systèmes Unix interdisent aussi les liens physiques vers des répertoires pour préserver une arborescence sans cycle. Dans le décompte classique des répertoires Unix, un répertoire vide a deux liens, provenant de son entrée dans le parent et de sa propre entrée .. Chaque sous-répertoire en ajoute un par .. ; trois sous-répertoires donnent un nombre de 5.

Stocke un chemin dans un lien symbolique

Un lien symbolique est un fichier distinct dont le contenu est un chemin vers la cible. ln -s /home/ana/report.txt r crée r avec le chemin cible de 20 octets comme contenu. Suivre le lien résout ce chemin. Les liens symboliques peuvent traverser les systèmes de fichiers et pointer vers des répertoires.

Un lien symbolique n’augmente pas le nombre de liens de sa cible. Conserver l’objet lien ne maintient donc pas la cible en vie.

Le contenu d’un fichier ne constitue qu’une partie de son état. Les métadonnées indiquent qui peut l’utiliser, sa taille et son type, ainsi que les dates de ses modifications. Le montage rend les objets de plusieurs systèmes de fichiers accessibles par une seule arborescence de noms.

Lis correctement les métadonnées

stat(path, &buf) lit les métadonnées à partir d’un chemin ; fstat(fd, &buf) les lit à partir d’un descripteur ouvert. Les résultats comprennent le numéro d’inode, le type, les permissions, les identifiants du propriétaire et du groupe, la taille, les blocs alloués et le nombre de liens. La taille du fichier compte les octets logiques ; les blocs alloués mesurent le stockage réellement utilisé, qui peut être inférieur pour un fichier creux.

Trois horodatages décrivent des événements différents :

ctime n’est pas la date de création. La mise à jour d’atime seule ne modifie pas ctime. L’appel Unix classique stat ne possède pas de champ de date de création ; sous Linux, statx peut exposer une date de naissance enregistrée lorsque le système de fichiers la prend en charge.

Décode les bits de permission

Les droits de lecture, d’écriture et d’exécution sont enregistrés séparément pour le propriétaire, le groupe et les autres utilisateurs. Chaque classe correspond à un chiffre octal : la lecture vaut 4, l’écriture 2 et l’exécution 1. Pour rw-r-----, le propriétaire reçoit 4 + 2 = 6, le groupe reçoit 4 et les autres reçoivent 0. chmod 640 report.txt définit ces bits.

Les permissions d’un répertoire s’appliquent aux noms et à son parcours. La lecture autorise à lister les noms. L’exécution autorise la recherche, c’est-à-dire l’utilisation du répertoire dans un chemin. L’écriture associée à l’exécution autorise à créer, supprimer et renommer des entrées. Connaître un nom peut suffire pour ouvrir un fichier dans un répertoire avec la permission d’exécution mais sans celle de lecture, à condition que les permissions propres au fichier autorisent l’accès. La tentative de lister ce répertoire échoue néanmoins.

Cette différence compte pour la suppression : retirer une entrée modifie le répertoire qui la contient. Le bit d’écriture d’un fichier contrôle la modification de ses octets ; ce n’est pas la permission du répertoire qui permet de supprimer son nom. Root contourne la plupart des vérifications ordinaires de permissions. Les listes de contrôle d’accès (ACL) peuvent accorder des droits à des utilisateurs et groupes nommément désignés, au-delà des trois classes de base.

Rattache un autre système de fichiers

mkfs initialise un système de fichiers sur une partition ou un autre périphérique, avec son propre répertoire racine et ses métadonnées. Il détruit le contenu précédent du système de fichiers sur le périphérique : exécute-le donc uniquement sur un périphérique destiné à être initialisé.

mount rattache cette racine à un répertoire existant appelé point de montage. Un disque monté sur /media/usb y rend accessible le contenu de sa racine. Le contenu précédent de /media/usb est masqué tant que le montage est actif ; le montage ne le fusionne pas avec l’arborescence montée. Exécuter mount sans argument liste les montages actuels.

La couche de système de fichiers virtuel (VFS) du noyau fournit une interface commune à ext4, XFS, FAT et aux systèmes de fichiers en mémoire ou en réseau. Les programmes peuvent appeler open et read sur chacun d’eux. L’espace de noms réunifié ne fusionne pas leurs tables d’inodes : des numéros d’inode identiques sur différents systèmes de fichiers peuvent désigner des fichiers sans rapport. Les liens physiques et les renommages atomiques restent donc au sein de leur propre système de fichiers.

Un système de fichiers doit mémoriser à la fois où se trouvent les octets et quel espace est disponible. Une organisation simple de type Unix rend ces fonctions visibles en séparant les informations d’allocation, les inodes et les contenus.

Divise la partition en zones

Un bloc est l’unité d’allocation de base du système de fichiers. Un bloc de 4 KiB contient 4 096 octets, soit huit secteurs traditionnels de 512 octets. Les tailles binaires utilisent KiB, MiB et GiB ; les débits de transfert comme MB/s utilisent des millions décimaux d’octets par seconde.

La conception pédagogique vsfs, le système de fichiers très simple, contient ces structures :

Un bit à 1 dans une table de bits signifie alloué ; 0 signifie libre. Le superbloc indique au système d’exploitation comment interpréter le reste de la partition lors de son montage. Les deux tables de bits décrivent des ressources différentes : un fichier peut avoir un inode alloué avant de posséder des blocs de données.

Localise un inode par son numéro

Prends une partition de 64 blocs de 4 KiB. Place le superbloc au bloc 0, la table de bits des inodes au bloc 1, la table de bits des données au bloc 2 et la table des inodes dans les blocs 3 à 7. Les données occupent les blocs 8 à 63. Cinq blocs de table des inodes contenant des inodes de 256 octets accueillent 80 inodes, car chaque bloc en contient 16. Il y a 56 blocs de données. Une table de bits de 4 KiB peut décrire 32 768 objets : une grande partie de chaque table reste donc inutilisée dans cette organisation miniature.

En numérotant les emplacements d’inode à partir de zéro, l’inode 37 commence à 37 × 256 = 9 472 octets du début de la table. Celle-ci commence à l’octet 12 288, ce qui donne l’adresse absolue 21 760 en octets. La division par 4 096 donne le bloc disque 5 avec un reste de 1 280. La division par 512 donne le secteur 42 avec un reste de 256. Lis le bloc ou le secteur qui contient l’inode, puis sélectionne ses octets à l’intérieur.

La méthode générale consiste à additionner l’adresse de début de la table en octets et le numéro de l’inode multiplié par sa taille. Distingue l’adresse de début de la table du déplacement de l’inode dans celle-ci. Omettre cette adresse de base conduit au mauvais bloc disque.

Sépare les noms, les métadonnées et les contenus

Un inode enregistre le type, les permissions, le propriétaire, la taille, les dates, le nombre de liens, les blocs alloués et l’emplacement des données. Il ne contient pas le nom du fichier. Le nom appartient à une entrée de répertoire, ce qui permet à plusieurs noms de partager un inode.

Un répertoire possède un inode de type répertoire et des blocs de données contenant ses entrées. Une entrée simple stocke un numéro d’inode, une longueur d’enregistrement, une longueur de nom et un nom. La longueur d’enregistrement permet de parcourir l’entrée entière, y compris l’espace réutilisable laissé par une suppression. Les grands répertoires bénéficient d’index : XFS utilise des arbres B et ext4 des index en arbre haché.

La création d’un fichier cherche un bit libre dans la table de bits des inodes et le positionne. L’allocation de données modifie de la même façon la table de bits des données. Un allocateur peut réserver une suite de blocs afin que le fichier puisse grandir de manière contiguë. La table de bits indique si un bloc est libre ; l’inode indique à quel fichier il appartient. Ces structures doivent concorder.

Un programme voit des déplacements consécutifs en octets, mais les blocs de données correspondants peuvent être dispersés sur le disque. Le système de fichiers doit associer chaque bloc logique du fichier à son emplacement physique.

Suis les pointeurs directs et indirects

Un pointeur direct dans un inode désigne un bloc de données. Avec des blocs de 4 KiB, le déplacement de 10 000 octets se trouve dans le bloc logique 2, car deux blocs entiers occupent 8 192 octets. Le déplacement dans ce bloc est de 1 808. Les blocs logiques commencent à 0 : le bloc 2 utilise donc le troisième pointeur direct.

Un pointeur indirect désigne un bloc contenant des adresses de blocs de données. Un bloc de 4 096 octets contenant des adresses de 4 octets accueille 1 024 pointeurs. Un pointeur à double indirection désigne un bloc dont les pointeurs mènent à 1 024 blocs indirects. La triple indirection ajoute un niveau supplémentaire. Cet index multiniveau est volontairement déséquilibré : les petits fichiers utilisent des pointeurs directs sans lecture supplémentaire de blocs de pointeurs, tandis que les gros fichiers subissent le coût des niveaux supplémentaires.

Pour un inode avec 12 pointeurs directs et un pointeur de chaque niveau d’indirection :

Ce sont les capacités de cette organisation de pointeurs. Les blocs de pointeurs occupent eux aussi du stockage, mais leurs octets ne font pas partie du contenu du fichier.

Compte les blocs de pointeurs nécessaires à un fichier

Un fichier de 5 MiB occupe 1 280 blocs de données de 4 KiB chacun. Attribue les 12 premiers aux pointeurs directs. Attribue les 1 024 suivants au bloc à indirection simple. Il reste alors 244 blocs de données.

Ces 244 blocs nécessitent une racine à double indirection et un bloc indirect en dessous. Au total, le fichier a besoin de trois blocs de pointeurs : le bloc à indirection simple, la racine à double indirection et son unique bloc fils. Ne compter que la racine à double indirection oublie le bloc fils qui contient effectivement les adresses des données. Compter les 1 024 blocs fils possibles gaspille de l’espace : seul le bloc fils nécessaire est alloué.

Compare les extensions et les chaînes

Une extension enregistre un bloc disque de départ et la longueur d’une suite. Une suite contiguë de 1 000 blocs peut utiliser une extension au lieu de 1 000 pointeurs distincts. Ext4, XFS et NTFS utilisent des extensions. Ext4 peut en contenir jusqu’à quatre dans son inode et utilise un arbre pour les suivantes. La fragmentation divise les suites et augmente le nombre d’enregistrements d’extensions nécessaires.

L’allocation chaînée suit une chaîne de blocs. La table d’allocation des fichiers (FAT) stocke les liens vers les blocs suivants dans une table distincte, généralement mise en cache en mémoire. Une entrée de répertoire indique le premier bloc, et atteindre un bloc situé loin dans le fichier nécessite de suivre les liens précédents. FAT n’utilise pas d’inodes Unix et ne prend pas en charge deux liens physiques vers un même fichier.

Des déplacements consécutifs ne prouvent jamais que les blocs sont physiquement contigus. L’allocateur choisit les emplacements et la structure de correspondance enregistre ces choix.

Un appel système peut nécessiter plusieurs opérations disque, ou aucune. Pour suivre le travail, examine les structures que le système de fichiers doit consulter et précise celles qui sont déjà en cache.

Parcours un chemin avant de lire le contenu

Dans le modèle simple sans cache, ouvrir /docs/plan.txt nécessite de lire cinq blocs :

1. L’inode racine, dont le numéro est connu.
2. Les données du répertoire racine, pour trouver docs.
3. L’inode de docs.
4. Les données du répertoire docs, pour trouver plan.txt.
5. L’inode du fichier.

Chaque répertoire tient dans un bloc et aucun bloc nécessaire n’est initialement en mémoire. Le système de fichiers vérifie les permissions et crée une entrée de fichier ouvert. L’ouverture a trouvé les métadonnées du fichier, mais n’a pas encore lu son contenu. Les systèmes ext2 et ext4 utilisent le numéro 2 pour l’inode racine.

Dans un modèle de lecture volontairement sans cache, chaque lecture de bloc lit ensuite l’inode du fichier, lit les données et écrit la date d’accès de l’inode. Deux blocs ajoutent six entrées-sorties, soit onze en comptant l’ouverture. Dans ce modèle, la fermeture ne nécessite aucune entrée-sortie disque. Ces nombres correspondent aux règles explicites de relecture et d’horodatage du modèle ; un cache réel les modifie.

Tiens compte de l’allocation lors de la création

Créer /docs/log.txt nécessite plus que de trouver un inode existant. Dans le même modèle simple, l’opération effectue quatre lectures pour les inodes et les données des répertoires racine et docs. Lire et écrire la table de bits des inodes ajoute deux entrées-sorties. Mettre à jour les données de docs ajoute une écriture. Lire et écrire le nouvel inode en ajoute deux, et mettre à jour l’inode de docs en ajoute une. Total : dix.

Chaque bloc de données nouvellement alloué ajoute cinq entrées-sorties : lire et écrire la table de bits des données, lire et écrire l’inode du fichier, puis écrire le bloc de données. Deux blocs donnent donc vingt entrées-sorties en comptant la création. Ce suivi compte les structures de données simples avant d’ajouter les échanges dus à la journalisation ou le comportement d’un cache réel.

Tenir un relevé aide : liste la structure, indique si elle est lue ou écrite et pourquoi. Une écriture de données nécessite aussi un enregistrement d’allocation et une mise à jour de pointeur. Une modification de répertoire modifie aussi les métadonnées de ce répertoire.

Laisse le cache modifier le suivi

Un succès de cache utilise un bloc déjà en mémoire. Linux utilise un cache de pages unifié partagé avec la mémoire virtuelle, et non un cache de fichiers de taille fixe séparé en permanence. Une nouvelle ouverture peut réutiliser les blocs de répertoire et d’inode du parcours précédent. Lire un contenu en cache ne nécessite aucune lecture sur le périphérique. La politique habituelle relatime de Linux évite aussi une écriture d’atime à chaque lecture.

La mise en tampon des écritures retarde l’envoi des blocs modifiés sur le disque. Deux créations de fichiers rapprochées peuvent mettre à jour la même table de bits des inodes en mémoire, puis ne l’écrire qu’une fois. Le système de fichiers peut réordonner le travail pour améliorer le débit. Un fichier temporaire de courte durée peut être créé et supprimé avant même que son contenu atteigne le stockage.

La mise en tampon améliore les performances, mais laisse une période pendant laquelle la durabilité n’est pas assurée. fsync met fin à cette période pour un fichier en attendant les écritures nécessaires. Sous Linux, O_DIRECT permet aux programmes adaptés de contourner le cache de pages lorsqu’ils gèrent leurs propres tampons ; contourner un cache n’est pas en soi la même opération que synchroniser le stockage durable.

Un disque dur peut transférer rapidement une longue suite d’octets une fois que sa tête les a atteints. De petites requêtes dispersées font perdre du temps en déplacements de tête et en attente de rotation. Le Fast File System modifie le placement pour que les opérations ordinaires sur les fichiers exploitent davantage la bande passante de transfert du disque.

Analyse l’ancienne organisation Unix

La première organisation Unix plaçait tous les inodes près du début et toutes les données des fichiers après ceux-ci. Lire un fichier pouvait donc nécessiter un long déplacement de tête entre les métadonnées et le contenu. Une liste des blocs libres dispersait progressivement les allocations au fil des créations et suppressions de fichiers. Même un fichier séquentiel pouvait donner lieu à de nombreux accès disque éloignés les uns des autres.

Les petits blocs de 512 octets aggravaient la situation. Chaque attente de positionnement ne permettait qu’un court transfert avant que la requête suivante ne nécessite un autre déplacement de tête ou une autre rotation. Des mesures historiques ont montré que l’ancienne conception n’atteignait parfois que 2 % de la bande passante du disque. Ce chiffre décrit la première conception mesurée, pas une limite fixe des interfaces Unix.

Le Fast File System (FFS), développé à Berkeley au début des années 1980, a conservé les appels habituels comme open, read et write tout en modifiant l’organisation et la politique d’allocation. Des blocs plus grands, généralement de 4 KiB, ont augmenté le nombre d’octets transférés par requête. Garder les métadonnées et le contenu proches a réduit la distance entre les requêtes liées.

Construis des groupes avec leurs propres ressources

Un cylindre est l’ensemble des pistes de même rayon sur les surfaces des plateaux d’un disque. FFS forme des groupes de cylindres à partir de cylindres voisins. Un fichier peut avoir son inode et ses données dans le même groupe, ce qui raccourcit le déplacement de tête entre les métadonnées et les données.

Chaque groupe contient une copie du superbloc, ses propres tables de bits d’allocation des inodes et des données, une partie de la table des inodes et des blocs de données. Le groupe ressemble à un petit système de fichiers, mais tous les groupes appartiennent à un même système de fichiers. Une copie du superbloc aide aussi à la reprise si une copie est endommagée. Ext4 conserve des copies dans certains groupes plutôt que dans tous.

Les disques modernes masquent leur géométrie physique. Ext2, ext3 et ext4 utilisent donc des groupes de blocs, des suites d’adresses de blocs logiques consécutives, pour atteindre le même objectif de localité sans dépendre des cylindres exacts.

Suis la création d’un petit fichier

Créer /docs/a.txt nécessite un inode libre, un bloc de données, des modifications des tables d’allocation et une nouvelle entrée de répertoire. FFS essaie de placer le fichier dans le groupe de son répertoire parent. Le nouvel inode, les données du fichier, les tables de bits et les mises à jour du répertoire peuvent alors se trouver à proximité.

L’opération nécessite toujours plusieurs mises à jour distinctes. Le regroupement économise du temps de positionnement ; il ne réunit pas toutes les métadonnées et données dans un seul bloc. Une organisation adaptée au disque réduit le coût d’accès à ces structures sans modifier les opérations sur les fichiers du programme.

FFS utilise les noms comme indices des fichiers auxquels un programme accédera ensemble. Il limite aussi l’espace qu’un gros fichier peut occuper dans un groupe, afin de concilier localité et place disponible pour les futures allocations.

Place les répertoires et les fichiers

Un nouveau répertoire va dans un groupe comptant relativement peu de répertoires et beaucoup d’inodes libres. Cela répartit les différents répertoires tout en laissant de la place pour leurs futurs fichiers. L’inode d’un fichier ordinaire va dans le groupe de son répertoire parent et ses données près de son inode.

Pour /a/b, /a/c et /a/d, les trois fichiers sont placés près du répertoire /a. Un fichier /b/f suit son propre parent /b, généralement dans un autre groupe. Cela exploite la localité dans l’espace de noms : un compilateur qui travaille sur un projet ouvre souvent plusieurs fichiers d’un même répertoire. L’appartenance à un même répertoire permet de prévoir les accès ; ce n’est pas une garantie pour chaque programme.

Fais une exception pour un gros fichier

Un gros fichier pourrait consommer les blocs libres de son groupe et forcer tous ses voisins futurs à aller ailleurs. FFS conserve la première partie, atteinte par 12 pointeurs directs, dans le groupe de l’inode. Avec des blocs de 4 KiB, cela représente 48 KiB. Les portions suivantes, chacune atteinte par un bloc indirect contenant 1 024 pointeurs, couvrent 4 MiB de données et vont dans d’autres groupes peu utilisés.

Cela sacrifie une partie de la localité au sein du gros fichier pour préserver celle des autres fichiers du répertoire. Le gros fichier subit une attente de positionnement entre les portions : chacune doit donc être assez grande pour que ce coût soit justifié.

Déduis la taille des portions

Supposons que le positionnement prenne T secondes et que le débit de transfert soit de R octets par seconde. Le transfert d’une portion C prend C/R secondes. La fraction du temps total consacrée au transfert est :

La résolution donne :

À 100 MB/s avec 10 ms de positionnement, R multiplié par T vaut 1 MB. Une portion de 1 MB nécessite 10 ms de transfert plus 10 ms de positionnement, ce qui donne 50 % de la bande passante maximale. Pour 90 %, multiplie 1 MB par 0,9/0,1 pour obtenir 9 MB. Pour 99 %, le multiplicateur est 99, ce qui donne 99 MB. Convertis les millisecondes en secondes avant de multiplier par MB/s. Le dénominateur comprend le temps de transfert et celui de positionnement ; diviser uniquement par le temps de transfert masquerait le surcoût.

Les débits de transfert ont progressé plus vite que les délais de positionnement : atteindre la même fraction du débit maximal exige donc des portions plus grandes à mesure que l’écart se creuse.

Adapte le stockage aux petits fichiers et préserve la compatibilité

FFS utilisait aussi des fragments de bloc de 512 octets pour que les petits fichiers ne gaspillent pas un bloc entier de 4 KiB. Les fichiers qui grandissaient étaient copiés dans des blocs entiers ; la bibliothèque C mettait les écritures en tampon par morceaux de 4 KiB pour réduire les déplacements répétés. Le paramétrage utilisé à l’époque laissait des écarts de rotation entre les blocs consécutifs afin que le bloc suivant demandé ne soit pas déjà passé devant la tête. Les tampons de piste modernes rendent cette technique inutile en récupérant une piste en interne.

Les noms longs, les liens symboliques et rename atomique étaient des fonctionnalités supplémentaires de FFS. L’accélération due à l’organisation elle-même ne nécessitait pas de modifier les programmes existants.

Pour un programme, un ajout en fin de fichier ressemble à une seule action. Sur le disque, il modifie plusieurs structures et une panne peut n’en laisser qu’une partie à jour. La cohérence après panne concerne la prévention ou la réparation de ces résultats partiels.

Suis trois écritures indépendantes

Ajouter un bloc de 4 KiB à la fin d’un fichier existant modifie :

• Db, le nouveau bloc de données contenant les octets ajoutés.
• I, l’inode avec une taille accrue et un pointeur vers ce bloc.
• B, la table de bits des données qui marque le bloc comme alloué.

Si les trois atteignent le stockage, la mise à jour cohérente prévue est obtenue. Si aucun ne l’atteint, l’ancien état cohérent subsiste. Le danger réside dans les six combinaisons partielles. Le périphérique peut réordonner les requêtes : les envoyer dans un ordre donné sans attendre n’établit donc pas leur ordre d’achèvement.

Classe chaque résultat partiel

Une incohérence se produit lorsque les métadonnées sont en désaccord, par exemple lorsqu’un inode revendique un bloc dont le bit d’allocation indique qu’il est libre. L’allocateur pourrait alors donner ce même bloc à un autre fichier. Une fuite d’espace disque réserve du stockage qu’aucun fichier ne peut atteindre. Les données parasites peuvent être plus difficiles à détecter : I et B concordent parfaitement alors que Db n’est jamais arrivé.

Db seul ne provoque pas de fuite d’espace alloué, car la table de bits permet toujours de réutiliser ce bloc. Écrire des octets à un emplacement libre ne revient pas à l’allouer. B seul provoque bien une fuite d’espace, car l’allocation a survécu sans pointeur propriétaire.

Distingue la structure du sens

Un outil de vérification peut comparer les pointeurs aux tables de bits. Il ne peut généralement pas déterminer si des octets plausibles sont ceux qu’un programme voulait enregistrer. Le résultat avec I et B montre cette limite : un fichier valide du point de vue de sa structure peut avoir un contenu incorrect.

La transition souhaitée est atomique sur l’ensemble de la mise à jour : la reprise doit retrouver l’ancien état complet ou le nouvel état complet. Un modèle de stockage simple ne garantit des écritures atomiques que pour un secteur, traditionnellement de 512 octets. Plusieurs blocs de système de fichiers dépassent cette unité : le système de fichiers doit donc construire un protocole plus robuste. Les garanties réelles d’écriture atomique dépendent du périphérique et de l’interface ; le protocole de journalisation doit faire tenir son enregistrement de validation dans l’unité atomique prise en charge.

La mise en tampon augmente le nombre de modifications susceptibles d’être perdues, mais elle n’est pas la cause première. Même en lançant immédiatement chaque écriture, une panne peut survenir entre deux fins d’écriture distinctes. La création, le renommage et la suppression de fichiers modifient aussi plusieurs structures. Pour comprendre leurs états après une panne, commence par le même exercice : identifie chaque bloc modifié et demande-toi ce qui se passe lorsqu’une partie seulement est conservée.

Un outil de vérification du système de fichiers répare les relations entre les structures stockées après l’apparition de dommages. Sa force est une vue d’ensemble des métadonnées ; ses faiblesses sont le coût du parcours et son ignorance du contenu attendu des fichiers.

Reconstitue l’état des allocations

fsck examine un système de fichiers arrêté incorrectement avant son montage normal. Il vérifie que la taille et les nombres indiqués par le superbloc sont plausibles et peut utiliser un superbloc de sauvegarde si la copie principale est endommagée.

Il parcourt ensuite les inodes et les blocs indirects pour déterminer les blocs de données réellement référencés par les fichiers. À partir de ces informations d’appartenance, il reconstruit les tables de bits d’allocation. Si un inode par ailleurs valide pointe vers le bloc 74 alors que la table de bits indique que 74 est libre, ce bloc doit être marqué comme alloué dans la table. Se fier uniquement à la table pourrait permettre à une allocation ultérieure d’écraser les données du fichier.

La discordance inverse est un bit marqué comme alloué sans pointeur d’inode propriétaire. Reconstruire la table peut récupérer cet espace. La réparation établit une relation cohérente ; elle ne peut pas reconstruire des octets arbitraires manquants d’une application.

Vérifie les objets, les noms et les liens

Chaque inode alloué doit avoir un type valide, comme fichier ordinaire, répertoire ou lien symbolique. Un inode irréparable est effacé et les informations d’allocation sont ajustées.

Le parcours depuis la racine permet à fsck de compter les références de répertoire à chaque inode. Il compare ces références observées aux nombres de liens enregistrés et corrige les erreurs. Un inode alloué qu’aucun répertoire n’atteint peut être déplacé dans lost+found, ce qui donne au contenu récupéré un nom accessible sans connaître son chemin d’origine.

Les autres vérifications comprennent :

• Propriété en double : deux inodes revendiquent un bloc de données. Une réparation peut effacer un inode ou donner à chaque fichier une copie distincte.
• Adresses invalides : les pointeurs hors de la plage valide du système de fichiers doivent être effacés.
• Structure des répertoires : . et .. doivent être valides et occuper les premières entrées dans l’organisation simple des répertoires, les entrées doivent désigner des inodes alloués et les répertoires ne doivent pas avoir plusieurs parents.

Ces vérifications interagissent. Effacer un inode invalide modifie aussi les blocs qui doivent être alloués et les entrées de répertoire qui restent valides. Une réparation nécessite donc une vue cohérente des métadonnées, pas seulement une liste de bits suspects pris isolément.

Comprends ce qu’établit un résultat sans erreur

Supposons que l’inode et la table de bits d’un ajout aient atteint le disque, mais pas ses données. Le pointeur est dans la plage valide, le bit d’allocation est positionné et la structure des liens est valide. fsck ne trouve aucun désaccord entre les métadonnées à réparer. Le fichier peut passer la vérification tout en contenant d’anciens octets dans sa zone nouvellement ajoutée.

La durée d’exécution dépend aussi principalement de la taille du système de fichiers, pas de la quantité modifiée avant une panne. Une panne pendant une seule mise à jour de trois blocs peut tout de même nécessiter le parcours de toutes les métadonnées. Sur un grand système de fichiers, cela peut prendre de plusieurs minutes à plusieurs heures et empêcher l’accès normal pendant le parcours.

La journalisation réduit le travail de reprise ordinaire après une panne en enregistrant les mises à jour récentes. Elle ne rend pas l’outil de vérification obsolète : des bogues logiciels ou une défaillance matérielle peuvent endommager des structures au-delà de ce que le rejeu du journal peut réparer. fsck reste un outil de réparation pour ces cas.

Un journal enregistre une mise à jour avant que le système de fichiers n’écrase les données à leurs emplacements ordinaires. Après une panne, cet enregistrement indique au processus de reprise quelles modifications complètes peuvent être refaites. C’est la journalisation préalable à l’écriture. Ext3, ext4, XFS et NTFS utilisent la journalisation, même si leurs formats de journal exacts diffèrent.

Décris une mise à jour comme une transaction

Pour un ajout, la journalisation des données enregistre des copies du nouvel inode I, de la table de bits B et du bloc de données Db. Un enregistrement de début de transaction, TxB, contient un identifiant et les destinations définitives des blocs. Un enregistrement de fin de transaction, TxE, contient l’identifiant correspondant et marque la validation.

Enregistrer les images complètes des blocs de remplacement est une journalisation physique. Enregistrer à la place une description de l’opération est une journalisation logique. La réexécution physique possède une propriété utile : écrire de nouveau la même image à la même adresse a le même effet. La reprise peut donc répéter la création d’un point de contrôle partiellement terminée avant la panne.

Place la validation après le contenu

Le protocole de base comporte quatre étapes :

1. Écriture dans le journal : écrire TxB, I, B et Db dans le journal et attendre leur écriture durable.
2. Validation : écrire TxE et attendre. La transaction est alors validée.
3. Création d’un point de contrôle : copier I, B et Db du journal vers leurs emplacements définitifs.
4. Libération : libérer l’espace occupé par cette transaction dans le journal pour le réutiliser plus tard.

TxE ne doit pas devenir durable avant son contenu. Si les cinq blocs étaient envoyés sans garantie d’ordre, un périphérique pourrait terminer TxB et TxE tout en laissant Db non écrit. La reprise prendrait alors une transaction incomplète pour une transaction valide. Dans le modèle de base, TxE tient dans une écriture atomique de secteur : il est donc présent ou absent en tant qu’enregistrement de validation complet.

Les caches d’écriture des périphériques doivent eux aussi respecter la limite de durabilité. Les vidages de cache ou les écritures forcées empêchent un cache volatile de périphérique de faire croire au protocole qu’un contenu est en sécurité alors qu’une coupure de courant pourrait encore l’effacer.

Reprends après deux points de panne

Une panne après le contenu mais avant TxE laisse une transaction non validée. La reprise l’ignore et conserve l’ancien état du fichier.

Une panne après TxE mais pendant la création du point de contrôle laisse une transaction validée. La reprise écrit dans l’ordre toutes ses images à leurs emplacements définitifs. Certaines écritures peuvent répéter un travail déjà effectué, ce qui est sans conséquence pour ces images de blocs. C’est la reprise par réexécution. L’espace du journal ne peut pas être réutilisé avant que les images validées aient atteint leurs emplacements définitifs.

Le journal est circulaire. Son superbloc suit la plage active, ce qui permet de réutiliser l’espace libéré. Regrouper plusieurs mises à jour en une transaction permet de ne journaliser qu’une fois un bloc de répertoire ou une table de bits partagés. L’intervalle de validation par défaut d’ext4 est de 5 secondes : la validation n’est donc pas automatiquement immédiate après chaque écriture d’une application.

Distingue les sommes de contrôle de la durabilité

Une somme de contrôle de transaction peut révéler des blocs de contenu manquants ou partiellement écrits même lorsqu’un enregistrement de validation est présent. Un protocole fondé sur des sommes de contrôle peut lancer ensemble les écritures du journal et n’accepter que les transactions dont la vérification réussit. Les sommes de contrôle détectent les enregistrements incomplets ; les vidages de cache établissent si les octets dont l’écriture a été confirmée survivent réellement.

Une écriture d’application mise en tampon et non validée peut toujours disparaître. Un programme qui exige une écriture durable utilise fsync et vérifie sa réussite.

La journalisation des données écrit le contenu des fichiers dans le journal, puis à son emplacement définitif. Ne journaliser que les métadonnées réduit ces échanges, mais l’ordre entre données et métadonnées détermine toujours ce que la reprise peut exposer.

Écris les données avant de valider les pointeurs

Dans la journalisation ordonnée des métadonnées, Db va directement à son emplacement définitif. TxB, I et B vont dans le journal. Ces deux ensembles d’écritures peuvent s’exécuter en parallèle, mais doivent tous deux se terminer avant que TxE valide les métadonnées. Après validation, I et B peuvent être écrits au point de contrôle et l’espace du journal libéré.

La dépendance est essentielle : le bloc désigné par un pointeur doit être prêt avant que ce pointeur puisse être restauré. Si I est validé en premier, la reprise peut installer un pointeur valide vers des octets laissés par un utilisateur précédent du bloc. Les métadonnées concorderaient sans que les données attendues soient présentes.

Le mode ordonné est le mode par défaut. La journalisation des seules métadonnées n’implique pas le mode ordonné : le mode writeback peut restaurer des fichiers structurellement cohérents dont le contenu est périmé. Le mode de journalisation des données illustre le protocole complet, mais impose une seconde écriture des données des fichiers.

Empêche le rejeu d’endommager un bloc réutilisé

Le contenu des répertoires est considéré comme des métadonnées. Supposons qu’un bloc de répertoire à l’adresse 1 000 soit journalisé, puis que le répertoire soit supprimé et que la même adresse serve aux données d’un fichier ordinaire. Ces nouvelles données utilisateur ne sont pas journalisées dans le mode qui ne journalise que les métadonnées. Rejouer l’ancienne image du répertoire après une panne écraserait les octets du nouveau fichier.

Un enregistrement de révocation validé indique à la reprise d’ignorer les copies journalisées de ce bloc issues des transactions jusqu’à la transaction de révocation incluse. Il n’interdit pas toute utilisation future de l’adresse. Si une transaction ultérieure journalise de nouveau ce bloc, l’image ultérieure peut toujours être rejouée. Cette limite temporelle distingue la révocation du marquage permanent d’un bloc comme inutilisable.

Compare les autres approches

Les mises à jour souples imposent des dépendances entre les écritures ordinaires sans journal. Écrire les données initialisées avant un pointeur empêche que des données parasites soient accessibles, même si des opérations interrompues peuvent laisser de l’espace inutilisé qu’une vérification ultérieure en arrière-plan récupérera. FFS de FreeBSD utilise cette approche. Le suivi de toutes les dépendances rend sa mise en œuvre difficile.

La copie sur écriture (COW) écrit les blocs modifiés à des emplacements inutilisés et utilise un changement atomique du pointeur racine pour publier le nouvel arbre. L’ancien arbre reste disponible jusqu’au changement. ZFS, Btrfs et WAFL utilisent des conceptions apparentées ; la conservation des anciens blocs permet aussi les instantanés.

Des conceptions issues de la recherche et fondées sur des pointeurs inverses enregistrent l’appartenance des données en pointant vers les inodes, afin que les mises à jour incomplètes laissent des discordances détectables. La cohérence optimiste après panne réduit l’attente et utilise des sommes de contrôle et d’autres vérifications pour détecter le travail incomplet. Chaque approche constitue un compromis entre les échanges dus aux écritures, les garanties de reprise et la complexité de mise en œuvre. La journalisation ordonnée des métadonnées maintient une reprise courte tout en n’écrivant qu’une fois les données ordinaires des fichiers.

Un système de fichiers structuré en journal transforme de petites mises à jour dispersées en grandes écritures séquentielles. Cela profite à un disque dont le débit de transfert est élevé, mais dont les temps de recherche et de rotation restent coûteux.

Regroupe les mises à jour dans un segment

LFS de Berkeley, développé par Rosenblum et Ousterhout et publié en 1991, partait de l’évolution des charges de travail. Des mémoires plus grandes servaient davantage de lectures depuis le cache, ce qui augmentait la part des écritures dans les échanges avec le disque. La bande passante séquentielle progressait plus vite que la vitesse de positionnement. FFS nécessitait encore plusieurs courtes écritures de métadonnées et de données pour créer un petit fichier, et les petites écritures fonctionnaient aussi mal avec le RAID à parité.

LFS met ensemble en mémoire tampon les données modifiées, les inodes et les informations de correspondance. Il les écrit dans une zone inutilisée du disque sous la forme d’un grand segment. La mise à jour d’un bloc crée une nouvelle version à une nouvelle adresse ; la version précédente reste physiquement présente jusqu’à ce que le nettoyage récupère son segment.

Les segments amortissent le positionnement tout comme les grandes portions de FFS. Avec un débit R, un temps de positionnement T et une fraction F souhaitée du temps consacrée au transfert, la taille mise en tampon est :

À 200 MB/s et 5 ms, atteindre 95 % nécessite 19 MB. Le transfert prend 95 ms, le positionnement 5 ms, et le débit effectif est de 19 MB par 0,1 s = 190 MB/s. Une fraction cible élevée peut nécessiter un segment plus grand que les tailles habituelles allant de plusieurs centaines de kilo-octets à plusieurs mégaoctets. La taille nécessaire dépend du périphérique et de l’objectif, pas du mot « segment ».

Retrouve un inode qui change sans cesse d’emplacement

La formule fondée sur une table d’inodes fixe ne fonctionne plus : chaque mise à jour d’un inode l’écrit à une nouvelle adresse. LFS ajoute une table de correspondance des inodes, ou imap, qui associe chaque numéro d’inode à son adresse disque la plus récente. Les morceaux mis à jour de la table sont écrits dans le journal à côté des inodes qu’ils décrivent.

Une zone de point de contrôle (CR) fixe indique où se trouvent les morceaux les plus récents de la table. Elle est mise à jour périodiquement, par exemple toutes les 30 secondes, de sorte que l’écriture occasionnelle à un emplacement fixe ne domine pas les échanges.

La chaîne de recherche est la suivante :

1. Lis la CR au montage pour trouver les morceaux actuels de la table.
2. Charge la table en mémoire.
3. Cherche le numéro d’inode demandé dans la table.
4. Lis cet inode le plus récent et suis ses pointeurs de données.

Une fois la table en cache, les lectures ordinaires suivent à peu près le même chemin de l’inode aux données que dans FFS. Cette correspondance supplémentaire permet de déplacer l’inode sans changer l’identité stable du fichier et sans coût excessif.

Garde les entrées de répertoire stables

Un répertoire stocke des noms et des numéros d’inode. Si /docs/report.txt est mis à jour, son inode change d’emplacement mais conserve son numéro. La table de correspondance change ; l’entrée de répertoire n’a pas besoin de changer simplement à cause de ce déplacement.

Sans cette indirection, un répertoire contenant les adresses physiques des inodes devrait être réécrit chaque fois qu’un inode fils change d’emplacement. Son propre inode changerait alors d’emplacement, imposant une modification de son parent, et ainsi de suite jusqu’à la racine. La table de correspondance interrompt ce problème des mises à jour récursives.

LFS rend les écritures séquentielles, mais pas toutes les lectures. Les blocs inchangés d’un fichier peuvent rester dans d’anciens segments tandis que les versions ultérieures d’autres blocs vont ailleurs. Lire ce fichier peut encore nécessiter des déplacements de tête entre segments ; les grands caches en mémoire font partie des raisons qui ont motivé cette conception.

Écrire de nouvelles versions à des emplacements inutilisés laisse les anciens octets physiquement présents. LFS doit distinguer les anciennes versions inaccessibles des blocs actifs, récupérer de grandes zones libres et retrouver une table de correspondance utilisable après une panne.

Nettoie des segments entiers

Le nettoyeur lit des segments partiellement occupés, copie leurs blocs actifs dans un plus petit nombre de nouveaux segments et libère les anciens. Si quatre segments de même taille contiennent chacun un quart de données actives, leurs données actives réunies remplissent un nouveau segment. Libérer les quatre anciens segments après la copie fait gagner trois segments de capacité utilisable.

Nettoyer des segments entiers préserve de grandes zones contiguës pour les futures écritures séquentielles. La copie a un coût : les blocs actifs sont lus et écrits de nouveau même si aucune application ne les a modifiés. Un disque presque plein dont les segments sont constitués en majorité de données actives peut nécessiter beaucoup de copies pour récupérer peu d’espace libre.

Détermine si un bloc est actif

Un récapitulatif de segment indique l’inode propriétaire de chaque bloc et son déplacement logique en blocs dans le fichier. Pour tester un bloc à l’adresse A, utilise la table de correspondance des inodes pour trouver la version la plus récente de l’inode propriétaire. Suis son pointeur pour le bloc logique enregistré. Si le pointeur est toujours égal à A, il s’agit de la version active. S’il pointe ailleurs, A est obsolète.

Par exemple, un récapitulatif associe l’adresse 600 à l’inode 14, bloc logique 2. L’inode 14 actuel fait pointer le bloc logique 2 vers l’adresse 920. Le bloc 600 est obsolète même si ses octets ressemblent à des données valides. Son état dépend de son accessibilité actuelle, pas de la date récente de son écriture ni de l’utilité apparente de son contenu.

Les numéros de version accélèrent l’élimination des blocs obsolètes. Supprimer un fichier ou le tronquer à zéro augmente sa version dans la table de correspondance des inodes. Un bloc de segment portant une version plus ancienne peut être classé comme obsolète sans lire l’inode.

La politique de nettoyage tient aussi compte des modifications attendues. Les segments chauds contiennent des blocs fréquemment écrasés ; attendre peut laisser davantage de leurs blocs devenir obsolètes sans les copier. Les segments froids changent peu : la politique initiale de LFS les nettoie donc plus tôt. La politique doit équilibrer la proportion de données actives, l’âge et l’espace disponible ; la température d’un segment ne suffit pas à mesurer le coût immédiat de copie.

Récupère la table de correspondance et le travail récent

LFS conserve deux zones de point de contrôle aux extrémités opposées du disque et alterne leurs mises à jour. Chaque mise à jour écrit un en-tête horodaté, le corps, puis un horodatage final correspondant. La reprise choisit la zone la plus récente dont le début et la fin correspondent. Une mise à jour plus récente interrompue ne remplace pas un point de contrôle plus ancien et complet.

Le point de contrôle peut ne pas inclure les segments terminés les plus récents. La reprise effectue donc une restauration en avant à partir de la fin du journal qu’il indique : elle trouve les mises à jour valides suivantes et les applique pour reconstruire la table de correspondance actuelle. Les données qui n’ont jamais formé une mise à jour valide et récupérable ne peuvent pas être recréées depuis la mémoire après une coupure de courant.

Des systèmes apparentés à copie sur écriture conservent les anciens blocs pour prendre en charge les instantanés ; ZFS, Btrfs et WAFL partagent cette idée générale. Les contrôleurs SSD utilisent couramment des couches de traduction flash structurées en journal, tandis que F2FS applique ces idées au niveau du système de fichiers pour le stockage flash. Chacun a toujours besoin d’un moyen de récupérer l’espace laissé par les versions obsolètes.

Un système de fichiers distribué conserve les fichiers sur un serveur tandis que les programmes des machines clientes utilisent les appels de fichiers habituels. Le client transforme ces appels en requêtes réseau. Les délais et les pannes soulèvent une question que les appels locaux masquent généralement : que doit faire un client lorsqu’il ne peut pas savoir si une requête s’est terminée ?

Garde l’état des fichiers ouverts sur le client

Le Network File System (NFS) de Sun est apparu dans les années 1980. NFSv2 a rendu son serveur sans état en ce qui concerne les fichiers ouverts. Le serveur stocke les fichiers, mais ne mémorise pas les descripteurs ni les déplacements courants de chaque client. Chaque requête contient assez d’informations pour être exécutée sans requête d’ouverture préalable.

Un identificateur de fichier indique le volume du serveur, le numéro d’inode et la génération de l’inode. La génération change lorsqu’un numéro d’inode est réutilisé, ce qui empêche un ancien identificateur de désigner accidentellement un autre fichier dans cet emplacement réutilisé.

Pour ouvrir /home/ana/notes.txt, le client part d’un identificateur racine et envoie LOOKUP pour home, ana et notes.txt. Il conserve l’identificateur obtenu dans son propre état des fichiers ouverts. La lecture des 4 premiers KiB devient une requête READ contenant cet identificateur, le déplacement 0 et le nombre 4 096. Fermer le descripteur local ne nécessite aucune requête CLOSE de NFSv2, car le serveur n’a aucune entrée de fichier ouvert à libérer.

Réessaie sans répéter un effet

Si aucune réponse n’arrive, le client ne peut pas distinguer une requête perdue, un serveur indisponible ou une réponse perdue. Il renvoie la requête après expiration d’un délai d’attente.

Une opération est idempotente lorsque la répéter a le même effet que l’exécuter une seule fois. READ, LOOKUP et GETATTR ne modifient pas le contenu stocké. Dans ce modèle, un WRITE avec déplacement explicite réécrit lui aussi sans risque les mêmes octets au même endroit. Répéter une requête demandant « ajoute ces octets à la fin actuelle » ajouterait au contraire une seconde copie ; le déplacement dans un WRITE NFS évite cette ambiguïté.

Certaines requêtes demandent plus d’attention. Réessayer un MKDIR réussi après la perte de sa réponse peut renvoyer « existe déjà ». Le répertoire est présent, mais la réponse à la répétition diffère du succès initial. La reprise sans état ne transforme pas toutes les opérations en requêtes faciles à répéter.

Rends les confirmations fiables

NFSv2 doit rendre un WRITE durable avant d’en confirmer la réussite. Sinon, le serveur pourrait confirmer un bloc, le perdre de sa mémoire lors d’une panne, puis accepter les blocs suivants. Le client croirait que toutes les écritures ont réussi alors qu’une mise à jour intermédiaire manquerait dans le fichier.

Les réponses après stockage stable évitent cette défaillance au prix d’une baisse de performance. NFSv3 a ajouté des écritures instables suivies de COMMIT, ce qui permet à plusieurs écritures de devenir durables ensemble. Le client doit distinguer la confirmation d’une écriture instable de la fin d’une écriture durable.

Distingue les versions du protocole

Un protocole avec état nécessite des mécanismes pour récupérer l’état des ouvertures et des verrous après un redémarrage du serveur et libérer l’état des clients tombés en panne. NFSv4 accepte délibérément cette complexité : il possède OPEN, CLOSE, des verrous et des baux limités dans le temps que les clients renouvellent. Le client Linux essaie normalement la version 4.2 en premier, puis utilise une version antérieure si nécessaire. Qualifier NFSv2 de sans état ne décrit donc pas toutes les versions de NFS.

La mise en cache côté client évite des échanges réseau, mais crée plusieurs copies des fichiers partagés. La règle de cohérence détermine quand une autre machine doit cesser d’utiliser une ancienne copie et récupérer les modifications du rédacteur.

Vérifie les caches NFS aux points de partage

Avec la cohérence de la fermeture à l’ouverture de NFS, fermer un fichier modifié envoie les écritures en tampon au serveur. Une ouverture ultérieure sur un autre client vérifie que les données sont à jour et voit ces modifications. GETATTR ou une vérification apparentée compare les attributs du serveur à ceux en cache et écarte les données en cache périmées lorsqu’un changement est détecté.

Vérifier à chaque accès surchargerait le serveur. Linux conserve par défaut les attributs des fichiers ordinaires en cache pendant des durées allant de 3 à 60 secondes. Un processus qui garde un fichier ouvert peut donc lire des données en cache périmées entre deux vérifications. L’ouverture constitue un point de partage plus fort qu’une lecture quelconque par un descripteur déjà ouvert. La cohérence de la fermeture à l’ouverture ne promet pas la visibilité immédiate de chaque écriture individuelle.

Réutilise des fichiers entiers grâce aux rappels AFS

L’Andrew File System (AFS) a été conçu à Carnegie Mellon dans les années 1980 pour prendre en charge de nombreux clients par serveur. Lorsqu’aucune copie locale valide n’existe, l’ouverture récupère le fichier entier sur le disque local. Les lectures et écritures utilisent ensuite cette copie, et la fermeture d’un fichier modifié envoie la nouvelle version entière au serveur. Une copie valide en cache peut être rouverte sans nouveau téléchargement.

AFSv1 vérifiait la validité à chaque ouverture et confiait la résolution des chemins au serveur. AFSv2 a transféré ce parcours aux clients, qui mettent les répertoires en cache, et a introduit les rappels. Le serveur promet d’avertir un client lorsqu’un objet en cache change. Tant que cette promesse n’est pas invalidée, le client réutilise sa copie sans vérifications répétées. Son identifiant de fichier comprend un volume, un identifiant de fichier et un identifiant d’unicité.

Suis deux sessions qui se chevauchent

Supposons que les clients A et B ouvrent tous deux un fichier. A modifie sa copie locale et la ferme, envoyant la nouvelle version au serveur. Le serveur invalide les rappels des autres clients. Une ouverture ultérieure sur B récupère la nouvelle version, mais la session déjà ouverte de B conserve sa copie existante jusqu’à sa fermeture et sa réouverture.

Si les deux machines modifient leurs copies, la dernière à fermer remplace le fichier entier du serveur. Les blocs des deux copies ne sont pas fusionnés. Deux modifications à des déplacements différents peuvent tout de même perdre les changements d’un client, car la cohérence selon la dernière fermeture choisit une version complète. Les processus d’une même machine cliente voient immédiatement leurs écritures respectives.

Les rappels font partie de l’état du serveur. Après le redémarrage d’un client, les fichiers en cache sont suspects, car des notifications peuvent avoir été manquées. Après le redémarrage d’un serveur, les clients doivent détecter la perte des promesses de rappel, grâce à des messages périodiques de présence ou à une notification du serveur, et vérifier de nouveau leur validité.

Adapte la mise en cache à la charge de travail

AFS proposait aussi un espace de noms global, des listes de contrôle d’accès et des volumes gérés par l’administrateur. AFSv2 a historiquement porté la capacité d’un serveur à environ 50 clients, contre environ 20 pour AFSv1. La règle de cache d’aucune des deux conceptions ne remplace une coordination explicite, comme des verrous de fichiers, lorsque les programmes ont besoin de mises à jour partagées sûres.