[Abstract] [Copyright Notice]

Étude sur l'évolution des systèmes de fichiers - Chapitre 4
La journalisation


La sécurité du système de fichiers passe en premier lieu par l'intégrité des données présentes. En effet, le système de fichiers doit pouvoir garantir que les données présentes restent bien cohérentes, même après un crash du système, et une récupération sur incident.

Comme on l'a vu dans la partie décrivant le système de fichiers ext2, le temps de redémarrage après un incident est proportionnel à la taille du système de fichiers présent. Le besoin s'est donc fait sentir de réaliser un système de fichiers ne possédant pas ce défaut. En effet, la conception des systèmes de fichiers actuels est basée sur une utilisation importante des techniques de caches de données pour la lecture des informations. Par exemple, sous Linux, et avec un noyau 2.2, on constate qu'une grande partie de la mémoire est utilisée, même sans faire tourner des applications gourmandes. Les informations du système de fichiers les plus utilisées sont stockées dans la mémoire vive, autant que possible. Bien entendu, si des programmes demandent de la mémoire, elle leur est attribuée au détriment du cache. Les systèmes actuels ont donc besoin de techniques d'optimisation de l'écriture sur disque. Les techniques de journalisation supposent que la lecture des informations sur le disques est déjà bien optimisée, et vont se contenter d'améliorer les technologies d'écriture des informations sur le support.


4.1 Récupération rapide sur incident

La définition et la sémantique de la récupération sur incident (crash recovery) varie suivant les environnements sous-jacents. Dans les environnements de transactions, les garanties données par les transactions ont un sens précis. Les modifications faites par les transactions validées doivent être présentes après le redémarrage, tandis que celles correspondant aux transactions non validées ne doivent pas être présentes. Le cas des systèmes de fichiers est légèrement différent car il n'a pas besoin d'autant de précision. Les systèmes de fichiers doivent redémarrer après un crash dans un état dans lequel les méta-données sont cohérentes et relativement à jour. On peut considérer par exemple que toutes les données plus vieilles que 30 secondes avant le crash devront être récupérées.

Les techniques utilisées pour récupérer un accident peuvent être classées dans deux grandes familles : les mises-à-jour prudentes, et les programmes "éboueurs". La première technique consiste à ne pas laisser le système de fichiers être incohérent à un moment précis. De cette manière, un crash peut survenir, le système sera toujours cohérent. Cependant, certains problèmes se posent, car ne pas passer par une étape laissant le système dans une position incohérente est une opération difficile. Par exemple, lors de la création d'un fichier dans un répertoire, il faut à la fois ajouter ce fichier dans la structure du répertoire et créer l'inode de ce répertoire. Le problème est que les deux opérations ne peuvent pas être effectuées en même temps, et il se passe toujours un instant où l'inode est affecté au fichier, mais pas encore référencé dans le répertoire, ou l'inverse. La technique de l'éboueur est la technique actuellement employée avec le système ext2. Il s'agit d'avoir un programme qui va remettre le système debout, en vérifiant son intégrité, comme le fait fsck. La lenteur de ce type de programme vient du fait qu'il vérifie l'ensemble des méta-données, alors que seule la vérification d'une seule partie d'entre elles est vraiment nécessaire.

Il est donc intéressant d'avoir une approche mélangeant les deux concepts. Dans le système journalisé, les opérations sont d'abord enregistrées dans le journal avant d'être effectuées physiquement sur le média. La latence entre l'écriture dans le fichier journal (log), et l'écriture sur le média représente le travail qui devra être réalisé en récupération après incident. Ce travail nous donne également une information sur la vitesse à laquelle la récupération aura lieu. Dans ce cas, elle sera fonction du nombre d'opérations qui doivent être vérifiées par le programme de récupération, et non plus de la taille du système de fichiers. Le nombre d'opérations restant à effectuer est limité par la présence régulière de points de contrôle (checkpoints) dans le journal. Ces points de contrôle sont écrits à la suite d'un ensemble d'opérations présentes dans le journal, et ayant été effectuées sur le média. Avec ces contrôles, une récupération consiste à repartir du dernier contrôle présent dans le journal, et de vérifier les opérations restantes. Quand la fin du journal est trouvée, le support a bien été mis à jour avec le journal. Ce processus de faire coïncider le support avec les informations contenues dans le journal est appelé "roll forward".

Le système peut donc contrôler le temps de récupération, et la performance du système de fichiers, en modifiant la fréquence de ces points de contrôle. Plus ces points seront proches, plus le système sera rapide à redémarrer en cas d'arrêt brutal. Cependant, les performances globales seront vraisemblablement assez affectées par ce réglage. Inversement, si ces points sont très éloignés, les performances du système de fichiers seront très bonnes, mais la récupération sera plus longue.

On peut remarquer qu'une fois qu'un point de contrôle a été placé dans le journal, le contenu du journal est redondant avec les structures sous-jacentes au système de fichiers. Cette partie du journal peut alors être effacée, pour garder une taille de journal raisonnable. Cependant, cette opération dépend de l'implémentation de la journalisation, ainsi que des caractéristiques demandées par les spécifications du système voulu. En effet, si on veut pouvoir annuler un certain nombre d'opérations sur le disque, le contenu du journal doit alors être gardé suffisamment longtemps pour répondre à cette approche.


4.2 Les structures de données

Il est possible de considérer que l'ensemble des méta-informations présentes sur le support sont dans le journal. Ce point de vue permet d'améliorer grandement les performances du système de fichiers, puisque l'intégralité des informations présentes dans la partie données du système de fichiers correspond directement à des données utilisateurs. Ainsi, le débit du périphérique sera entièrement réservé au transport d'informations directement utilisables, sans être pollué par des méta-données inutiles pour l'utilisateur. Cependant, bien que cette idée soit séduisante, elle pose des problèmes importants. En effet, si l'écriture de données est particulièrement efficace avec ce principe, il se pose le problème de la récupération de ces données depuis le support. En effet, comme le journal n'est pas destiné à être lu régulièrement, on peut raisonnablement n'y enregistrer que les modifications apportées au système de fichiers. Le système devra donc parcourir le journal dans son ensemble afin de retrouver le contenu exact d'un fichier. Ceci pose évidemment un problème de performances. Mais cela pose également un problème sur la taille du journal. En effet, si le journal compose la seule structure de données du disque, il est impensable d'effacer les données qu'il contient. On a donc un journal à la taille forcément croissante à mesure des modifications sur le système de fichiers.

Cette remarque nous amène donc à considérer une structure particulière pour le journal. En effet, regrouper l'ensemble des informations dans le journal pénalise beaucoup la lecture même de ces informations. La solution la plus intéressante est de permettre la création d'un index dans le journal, pour permettre de récupérer l'ensemble des informations relatives à un fichier, ou une autre structure de données du disque, sans avoir à parcourir l'ensemble du journal. La méthode traditionnelle d'accès aux fichiers avec les inodes est gardée, mais les inodes eux-mêmes sont stockés au niveau du journal. Le problème est que dans le cas de ext2, les inodes sont à des endroits fixes, accessibles par un simple calcul. Il faut donc que l'accès aux inodes présents dans le journal ne nécessite pas plus de temps que ce calcul, pour garder des performances acceptables. L'accès aux inodes peut donc être fait en stockant leurs positions dans une carte, cette dernière étant présente avec chaque point de contrôle.


[Abstract] [Copyright Notice]

Étude sur l'évolution des systèmes de fichiers
$Revision: 1.24 $ du $Date: 2000/07/04 12:17:41 $
Yves Rougy yves.rougy@alcove.fr