Journalisation Ext2 - Linux Magazine France No 6

Avec la version 2.2 diffusée il y a peu, les projets se remettent à fleurir dans la communauté des développeurs. Depuis un certain temps, aucune nouvelle fonctionnalité n'a réellement été ajoutée à la version officielle du système de fichiers Linux, ext2fs. Il semble que des changements soient dans les cartons, prêts à sortir dès que la nouvelle version de développement, la 2.3, sera lancée. Plutôt que de modifier le système existant qui fonctionne très bien, une nouvelle mouture, ext3, sera intégrée.

Cet article s'inspire d'un papier écrit par Stephen Tweedie et qu'il a présenté lors de la conférence Linux (Linux Expo) à San Jose (Californie) au mois de Mars 1999, ainsi que d'une version bêta du code source qu'il a eu la gentillesse de m'envoyer.

L'implémentation d'un système de fichiers est le fait de pouvoir convertir une séquence de données situées sur un support physique (disque, disquette, etc.) en une structure de données (souvent un arbre ou graphe) exploitable par les programmes utilisateurs. Le système de fichiers utilisé à l'heure actuelle sous Linux est ext2fs (seconde version d'Extented FileSystem). Il a remplacé de façon définitive la première mouture, extfs, au fil du temps en raison de sa stabilité et surtout de ses excellentes performances.

Ext2fs a été principalement écrit par Rémy Card, avec les actives contributions de Stephen Tweedie, Theodore T'so et Eric Youngdale, en se basant partiellement sur le système de fichiers initial (extfs) écrit par Linus Torvalds. Ext2 est d'une stabilité remarquable, et plutôt que « d'ajouter » de nouvelles fonctionnalités qui pourraient mettre en péril cette stabilité, il a été décidé de partir sur un nouveau système de fichiers. Cela explique le changement de nom, même si une grosse partie du code sera conservée : pourquoi refaire ce qui fonctionne déjà très bien.

Les fonctionnalités actuelles du système Ext2Fs, telles que l'on peut les trouver dans la version courante de Linux, sont les suivantes :

- fonctionnalités standards d'un système de fichiers Unix (fichiers réguliers, spéciaux, liens symboliques, etc.) ;

- suppression sécurisée (les données supprimées sont écrasées physiquement sur le disque) ;

- lectures de blocs et d'entrées de répertoire par anticipation (ce qui accélère grandement les entrées/sorties) ;

- l'état d'un système de fichiers est conservé, ce qui facilite les opérations de vérification.

Certains patch existent pour ajouter les fonctionnalités suivantes, mais avec une stabilité plus ou moins démontrée, et n'ont jamais été inclus de façon officielle au noyau :

- support de fichiers de plus de 2GigaOctets sur Intel (ce support existe déjà sur les plates-formes 64 bits telles que les Alpha et Sparc).

Non seulement les patch précédents n'ont jamais été inclus de façon officielle dans le système de fichiers, mais certaines fonctionnalités commencent à manquer, comme la Journalisation. Les systèmes de fichiers journalisés existent déjà dans certains systèmes d'exploitation tels que BeOS, SCO, Unixware, Dec OSF/, OpenVMS, etc.

Lorsqu'un système se réamorce après un arrêt brutal, il devra passer un certain temps à vérifier (et éventuellement à corriger) les différents systèmes de fichiers jusqu'à ce qu'ils soient dans un état « stable ». Cela a pour inconvénient de laisser la machine indisponible pour quelques heures si vous avez plusieurs dizaines de Go à vérifier.

Le principe de la journalisation est de supprimer autant que possible l'étape de la vérification de la stabilité du système de fichiers en s'assurant que les données soient toujours dans un état stable sur le système de fichiers (et donc ne peuvent être endommagées). Les fichiers dans cet état stable ne peuvent pas être modifiés lors d'une réparation du système de fichiers. Le seul point délicat concerne les fichiers en cours de modification lors du crash de la machine. Cela est déja fait dans la version actuelle d'Ext2. Toutefois, pour mettre en place ce système, les modes d'échec doivent être prévisibles et surtout les opérations de réparation doivent être atomiques. Ces deux derniers éléments n'existent pas dans Ext2.

La journalisation introduit une notion de base de données de transaction (ou journal des transactions, ce qui explique le nom de cette technique). Avant que toute information résultant d'un appel système soit réellement écrite dans le système de fichiers, les transactions résultant de l'appel système (commande et données) sont écrites dans un journal, ce qui résout le problème d'atomicité. Si un crash se produit, le système de vérification n'aura qu'à parcourir le journal pour "reconstruire" les transactions qui n'ont pas eu le temps d'être officialisées dans le système de fichiers. De cette manière, le système de fichiers est *toujours* dans un état stable, ce qui réduit considérablement le risque de corruption.

Une transaction peut être définie en réalité comme étant exactement une requête unique au système de fichiers effectuée par une application. L'opération d'écrire dans un fichier va en réalité provoquer plusieurs transactions : modification des champs horaires de la structure de l'inode du fichier, modification de la taille du fichier si nécessaire, enregistrement des données dans un ou plusieurs blocs, mettre à jour les listes de blocs libres, etc. Chacune de ces transactions doit être enregistrée dans une espèce de base de données simplifiée.

L'enregistrement d'une transaction va également provoquer des accès au système de fichiers et implique une certaine organisation pour ne pas rompre les dépendances entre transactions et système de fichiers. L'ensemble des transactions va constituer une mini base de données. Mini car peu d'opérations sont réellement nécessaires. De plus, la durée de vie des transactions est très courte - en effet, elles ne servent qu'à garder la trace des opérations qui doivent être effectuées et qui ne l'ont pas encore été par manque de temps, cache, etc.

Le format d'une transaction est simple : un bloc de données et un descripteur associé à ces données. Ce données sont écrites de façon séquentielles, donc rapidement. Des données supplémentaires (blocs d'en-têtes) se trouvent à des endroits fixés du journal. Ils contiennent les positions de tête et de fin du journal, etc. Ces en-têtes facilitent le parcours du journal lors d'une opération de réparation du système de fichiers.

Lorsque le système décide de mettre à jour le système de fichiers, il lui suffit de parcourir les transactions et d'effectuer les opérations. Comme chaque opération est atomique, même si un crash intervient, cela n'est pas un problème: il n'aura qu'à reprendre la mise à jour là où il s'était arrêté. L'opération de mise à jour (ou application des transactions sur le système de fichiers) s'effectue en utilisant un thread noyau spécial. Lorsque la transaction a bien été effectuée, elle reçoit un drapeau particulier. Une fois que toutes les transactions ont été parcourues, le journal est mis à jour : les transactions effectuées sont supprimées du journal.

D'après les premiers tests effectués, la compatibilité est totale : en gros, vous pouvez très bien changer le mode du système de fichiers. Le système Ext2fs, dans la définition des inodes, avait quelques paramètres réservés pour de futures utilisations. Le système de journalisation se sert des champs non utilisés à l'heure actuelle dans la version officielle pour enregistrer le journal. Cela explique pourquoi la compatibilité est conservée.

Toutefois, signalons que le fait d'utiliser ces inodes réservées a toujours été un peu un problème compte tenu du fait que pratiquement toutes les extensions non inclues à Ext2 (compression, etc) utilisent déjà ces champs. Il est donc fort probable qu'elles ne soient pas compatibles entre elles - à moins que les développeurs se décident enfin à tout inclure dans Ext3 (ACL, compression, journalisation, etc.).

Ces nouvelles fonctionnalités sont en cours de développement. Comme un système de fichiers est un élément clef d'un système d'exploitation, ne vous attendez pas à le voir dans votre système préféré d'ici quelques jours. Une longue phase de tests, d'optimisation devra être effectuée. Il est en réalité fort probable que ext3 ne sera intégré que dans la future version de développement 2.3 qui devrait voir le jour d'ici quelques semaines. Toutefois, il est rassurant qu'après une certaine pose, de nouvelles fonctionnalités importantes recommencent à être intégrées. Le fait de conserver ext2 tel quel est probablement le choix de la sagesse compte tenu du fait qu'il répond aux principaux besoins actuels.

- Programation Linux2.0 (chapitre sur les systèmes de fichiers et Ext2 en particulier), Card/Dumas/Mével, Ed. Eyrolles.

© Copyright 2000 Diamond Editions/Linux magazine France. - Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1or any later version published by the Free Software Foundation; A copy of the license is included in the section entitled "GNU Free Documentation License".

Journalisation du système de fichiers ext2 : en route pour ext3 !