[Abstract] [Copyright Notice]

Étude sur l'évolution des systèmes de fichiers - Chapitre 5
Exemples de systèmes de fichiers


5.1 Les systèmes chiffrés


5.1.1 CFS

CFS est l'acronyme de Cryptographic File System. C'est un système de fichiers conçu pour stocker des informations sensibles sur des machines Unix. Il a été écrit par Matt Blaze dans les années 1995-1996. Son principe est de se comporter comme un serveur NFS (voir les systèmes de fichiers distribués) particulier, n'acceptant que des requêtes locales. Ainsi, les fichiers sont cryptés depuis le point de vue de l'utilisateur. De plus, ce système repose sur un système de fichiers traditionnel pour stocker physiquement les données sur le média. Il s'agit donc d'un système de fichiers permettant d'étendre les possibilités du système sous-jacent, sans le remplacer.

Les spécifications demandées pour la création de ce système sont les suivantes :

Un des défauts de ce système, est qu'il oblige les utilisateurs à utiliser un répertoire particulier (/crypt en général) dans lequel les fichiers seront cryptés. Tous les fichiers se trouvant ailleurs ne seront pas cryptés.

Bien que la version originale de ce programme utilise le DES comme algorithme de cryptage, une adaptation a été faite de manière à utiliser Blowfish à la place. Cette version est disponible sur http://drt.ailis.de/crypto/cfs-1.3.3bf.1.tar.gz.


5.1.2 TCFS

Le système TCFS est un système qui se base sur CFS pour offrir des services de cryptographie au dessus d'un autre système de fichiers. Il est possible d'utiliser divers algorithmes de cryptographie tels que 3DES ou RC5. Le principal avantage de TCFS sur CFS est la performance. En effet, les auteurs de TCFS se sont principalement penchés sur les performances du système. De plus, alors que CFS fonctionne totalement dans l'espace utilisateur du système, TCFS est un module du noyau, et fonctionne dans l'espace noyau. Cela résulte donc par une meilleure performance, mais cela implique de patcher les sources du noyau pour l'utiliser. De plus, seuls des patches pour les noyaux 2.0.x sont disponibles, alors que la génération de noyaux utilisés actuellement est la 2.2.x. Néanmoins, avec TCFS, il n'est pas nécessaire que les utilisateurs regroupent les fichiers qu'ils veulent crypter dans un répertoire particulier, il s'agit simplement d'un attribut qui va spécifier que tel ou tel fichier sera crypté.

En raison du support de ce système pour les noyaux 2.0.x exclusivement, les systèmes journalisés ne sont pas supportés, car ceux-ci se basent sur des noyaux plus récents (au moins 2.2.x).


5.1.3 StegFS

StegFS est développé par Andrew McDonald et Markus Kuhn, en se basant sur les idées de l'étude faite par Anderson, Needham et Shamir. L'implémentation est très proche de la description de l'étude.

Il se base sur le système de fichiers traditionnel ext2. Le système résultant peut d'ailleurs être monté en tant que système de fichiers ext2 traditionnel. Quand il est monté en tant que système de fichiers stegfs, et que les mots de passes sont correctement donnés, des données cachées du système de fichiers sont accessibles. Différents niveaux sont accessibles, ce qui signifie que, en fonction du mot de passe donné, certaines données peuvent rester cachées.

Il est à noter que les données cachées sont invisibles, autant pour l'utilisateur, que pour le noyau et pour le système de fichiers lui-même. Le fait de donner un bon mot de passe permet d'en connaître l'existence, par ces entités. Les données sont chiffrées avant d'être cachées dans le système. Comme les données sont totalement invisibles, il est possible que le système de fichiers traditionnel, ne les voyant pas, écrive des données là où étaient présentes des données cachées. Pour résoudre ce problème, chaque bloc de données est écrit en plusieurs endroits du disque. Ceci implique un important ralentissement des opérations sur ces fichiers cachés, notamment au moment de l'écriture.

Ce risque d'écrasement des données n'est pas un bug de l'implémentation du système, mais bien une conséquence nécessaire à la possibilité de réfutation de l'existence même de ces données cachées.

Ce système se présente comme un patch des sources du noyau, et d'un ensemble d'utilitaires permettant d'utiliser les capacités stéganographiques de ce dernier.

Au niveau des fonctionnalités, la compatibilité avec le système ext2 permet de faire complètement disparaître le pilote Stegfs d'une machine, tout en y laissant des données cachées. Au niveau de l'implémentation, le système Stegfs se base sur des inodes à la structure modifiée pour prendre en compte les copies redondantes des blocs de données cachées (et donc susceptibles d'être effacées). Les détails de ce système sont disponibles dans le document http://www.cl.cam.ac.uk/~mgk25/ih99-stegfs.pdf, et sur le site http://ban.joh.cam.ac.uk/~adm36/StegFS/.


5.2 Systèmes journalisés


5.2.1 Le système ReiserFS


5.2.1.1 État d'avancement du projet

Ce projet est vraisemblablement le plus avancé des systèmes journalisés présentés. S'il est encore en version bêta, il n'en demeure pas moins utilisable. C'est d'ailleurs ce système qui a été mis en place sur des plate-formes de courrier électronique faisant un usage intensif des petits fichiers très nombreux. Des tests effectués ont montré le bon comportement de ReiserFS dans ces situations.

En ce qui concerne les ACL, le système ReiserFS n'en possède pas actuellement. Cependant, il est déjà prévu de les implémenter dans une prochaine version de ReiserFS. De même, une prochaine version du système de fichiers intégrera vraisemblablement une autre structure de données que les arbres B*. Cette nouvelle structure de données a pour objectif d'augmenter d'une manière significative les performances du système de fichiers.


5.2.1.2 Structures des données

Afin d'optimiser le stockage et la récupération des petits fichiers, une approche différente de l'approche traditionnelle a été effectuée. En effet, au lieu de représenter tous les fichiers de la même manière, le système les traite différemment selon leur taille. Pour cela, au lieu de référencer les fichiers à l'aide des inodes, ils sont directement référencés à l'aide de leur index dans un arbre. On retrouve donc le bloc occupé par un fichier en regardant la référence renvoyée par l'élément de l'arbre correspondant à son index. On a de cette manière également des références directes et indirectes, comme avec les inodes. Si la place utilisée par un petit fichier, ou par la fin d'un gros fichier, est inférieure à la taille du bloc, il est stocké directement dans l'arbre. Pour cela, la feuille de l'arbre correspondant contient un agrégat de petits fichiers ou de fins de fichiers. On voit donc bien que les très petits fichiers sont ici traités d'une manière complètement différente des gros fichiers.

La structure même des blocs de données est de trois formes :


5.2.1.3 La journalisation de ReiserFS

Bien que l'approche prise par les développeurs de ReiserFS soit particulière, ils n'ont pas inclus la journalisation dans les caractéristiques de base de leur système. Elle n'a été ajoutée que plus tard. Les spécifications demandées à cette journalisation étaient de permettre un redémarrage très rapide du système après un crash, en gardant le système de fichiers cohérent, et sans pénalités sur les performances du système.

Bien entendu, les données sont donc écrites dans le journal avant de l'être dans les structures de données du média. Pour cela, les opérations sont découpées en transactions. Chacune de ces transactions consiste en un bloc de description, suivi par un certain nombre de blocs de données et enfin par un bloc de validation (commit block). Le bloc de description et le bloc de validation contiennent une liste séquentielle de la position réelle sur le média de chaque bloc du journal.

Il est également possible de permettre plusieurs transactions par opération. Puisque certains blocs sont journalisés sans arrêt, cela diminue le nombre de blocs à écrire dans le journal. Cependant, cela augmente les chances que l'opération soit annulée par un crash. Les paramètres régissant ces groupes de transactions sont réglables assez finement par les personnes maîtrisant bien le système ReiserFS.

En extension à ces groupes de transactions, il est possible de permettre à une transaction d'être validée sans que tous ses blocs ne soient transférés sur le support. Cela ajoute de la complexité dans le code, mais cela permet aux opérations de se terminer plus rapidement, et par là libérer des éventuels verrous qu'elles peuvent avoir utilisés.

De plus, si un bloc de données est alloué puis libéré avant d'avoir été écrit sur le disque, ou enregistré dans le journal et libéré avant que la transaction n'ait été validée, le bloc n'est jamais écrit physiquement sur le disque ou dans le journal.


5.2.2 Le système XFS

Le système XFS a originellement été développé par Silicon Graphics (SGI) pour son système IRIX en 1994. Cependant, devant l'ampleur de Linux et des logiciels développés sous la licence GPL, SGI a annoncé début 1999 la mise sous GPL de XFS et le début du portage sur le système Linux. Après avoir été correctement épuré des fonctions l'empêchant d'être publié sous GPL, SGI a enfin pu le proposer à la communauté des logiciels libres. La première version proposée sur leur site date de la fin du mois de mars 2000. Il s'agit d'un patch appliqué à la dernière version du noyau de développement de Linux de l'époque (2.3.99pre2). Une compilation et une installation rapide montrent que le système est déjà prêt pour faire quelques tests. Cependant, SGI annonce qu'il pourra sortir en version bêta à partir de l'été 2000.


5.2.2.1 Spécifications

Pour répondre à une demande de débit que ne pouvait pas fournir le système de fichiers précédent de SGI (EFS), une étude a été lancée afin de définir un nouveau système de fichiers, performant, et comblant le maximum des attentes présentes (en 1994) et à venir. Ces attentes étaient tout d'abord au niveau de la performance du système de fichiers lui-même. Le goulet d'étranglement de leur système global ne se trouvant pas au niveau du débit des disques et des supports physiques, mais bien au niveau du système de fichiers. La taille maximale du système de fichiers de EFS, de 8 Go, se faisait ressentir comme un obstacle, de même que la taille maximale des fichiers (2 Go). De plus, devant de telles tailles, les redémarrages sur incidents étaient beaucoup trop lents. Les caractéristiques demandées étaient donc :

Pour répondre à ces attentes, en ayant de bonnes performances, les structures d'arbres B* sont utilisées, comme dans le système ReiserFS. Tout comme dans ce dernier, la structure linéaire de la représentation des informations sur le disque, est remplacée par une représentation sous forme d'arbre. Cependant, contrairement à ReiserFS, la journalisation du système fait partie de la conception initiale du système de fichiers, et il n'existe pas de séparation entre les petits fichiers et les autres fichiers.

La partie centrale du système XFS est le "gestionnaire d'espace" ou space manager. Cette partie s'occupe de l'espace libre du système de fichiers, de l'attribution des inodes, et de l'attribution d'espace dans chaque fichier. On trouve également un gestionnaire pour satisfaire les demandes d'entrées/sorties (I/O manager). Ensuite, le gestionnaire des répertoires s'occupe des noms du système de fichiers. Enfin, le gestionnaire des transactions s'occupe quant à lui de rendre toutes les opérations sur les méta-données atomiques.

Pour répondre aux attentes des utilisateurs, les ACL sont intégrées dans le système de fichiers.


5.2.2.2 La journalisation

Les mises à jour des méta-données sont d'abord écrites dans une file d'attente de type FIFO. Ces informations sont ensuite écrites de manière asynchrones sur le support. Le journal est circulaire, ce qui signifie que les informations sont écrites sur la tête du journal, et que les transactions qui on été validées sur le support sont effacées de la queue du journal. L'emplacement qu'elles utilisaient peut alors être pris par la tête du journal. Les opérations de récupérations se font en lisant le journal, depuis sa tête vers sa queue.

Les méta-données du journal correspondent à des opérations atomiques du système de fichiers. De cette manière, l'opération a soit eu lieu, soit n'a pas eu lieu. Elle ne peut pas avoir été partiellement exécutée. De plus, ces méta-données ne sont pas que descriptives, mais contiennent les informations qui sont modifiées. Ainsi, si le système subit un arrêt brutal, le programme qui vérifiera l'intégrité du système lors du redémarrage pourra refaire les modifications présentes dans le journal, même si celles-ci avaient déjà été faites. Par exemple, si le journal précise qu'un bloc particulier doit maintenant contenir la valeur FF, il mettra FF dans ce bloc, que FF y soit déjà ou pas. Ce cas peut se produire lorsque seulement quelques opérations atomiques constituant une transaction ont pu être effectuées, sans être validées, avant le crash.


5.2.2.3 Les ACL

Les ACL implémentées dans XFS sont considérées comme des attributs particuliers du système de fichiers. La modularité du code de XFS a permis de réaliser un "Attribute Manager" qui a pour rôle de s'occuper de l'ensemble des attributs des fichiers. La place des ACL dans le système se trouve donc dans ce gestionnaire d'attributs. Les ACL sont directement considérées comme des attributs particuliers sur les droits d'accès aux fichiers.

D'un point de vue technique, la manière de stocker les informations relatives aux informations des ACL est indépendante de leur utilisation. Les informations stockées dans les extrémités de l'arbre B* contiennent des champs utilisés pour des attributs complémentaires. Les informations des ACL ont donc été placées comme attributs. Lors de l'accès à un inode, il suffit que le pilote du système de fichiers fasse une requête au gestionnaire d'attributs afin de connaître les droits d'accès au fichier associés à cet inode.


5.2.3 Le système ext3

Le système ext3 correspond à une évolution logique du système traditionnel ext2. C'est une extension du système ext2 pour supporter la journalisation. L'intérêt d'ajouter des fonctionnalités de journalisation au système ext2 est multiple. Tout d'abord, et comme dans le cas du système ReiserFS, la journalisation n'entre pas en conflit avec la structure des données présentes dans le système de fichiers. Il est donc possible, dans le cas ext3, de garder une compatibilité avec le système ext2. Un support physique utilisant le système ext3 pourra donc être utilisé sur une machine ne supportant que le système de fichiers ext2. En résultat, il n'est pas nécessaire de ré-écrire un système de fichiers complet avec ses outils, mais d'étendre l'existant.


5.2.3.1 Structure des données

Etant donnée que la structure des données du système ext2 sera utilisée comme support, la nouvelle structure comprenant le journal doit s'y intégrer. On a vu que les systèmes de fichiers traditionnels Unix stockaient leurs données sur disque en associant chaque fichier avec un inode sur le disque. La conception du système ext2 inclut déjà un certain nombre d'inodes réservés au système . Un de ces inodes réservés sera donc utilisé pour stocker le journal du système de fichiers, et de cette manière, on garde bien une totale compatibilité avec le système existant. La conception de ext2 permet également d'avoir des cartes de compatibilités (bitmap) dans lesquelles on peut spécifier que le système de fichiers utilise des extensions. En allouant un nouveau bit de compatibilité dans ces cartes, on peut même permettre aux anciens noyaux ne supportant pas la nouvelle version du système de fichiers, de pouvoir le monter, mais en en interdisant l'écriture de quelque manière que ce soit (puisque l'interdiction se trouve au niveau du système de fichiers lui-même).


5.2.3.2 Format du journal

Le rôle du journal, on l'a vu, est simple. Il s'agit d'enregistrer le nouveau contenu des blocs de méta-données pendant le processus de validation de la transaction. L'autre rôle du journal est qu'il doit atomiquement valider les transactions qu'il contient. On trouvera trois types de blocs dans le journal :

Le bloc de méta-données du journal stocke le contenu d'une méta-donnée du système de fichiers mis à jour par la transaction. Cela signifie que quelque soit la taille de la modification faite sur le bloc de méta-données du système de fichiers, on écrit un bloc complet du journal. Cela reste raisonnable car l'écriture du journal reste rapide. En effet, les entrées du journal sont séquentielles, et elles peuvent être facilement regroupées pour être envoyées sur le disque. C'est une opération qui est en général très bien optimisée par les contrôleurs de disques. De plus, écrire complètement le contenu des méta-données modifiées nous permet d'éviter un certains nombre d'opérations par le processeur, celui-ci restant disponible pour d'autres tâches. Le noyau Linux contenant des mécanismes très efficaces permettant d'écrire le contenu d'un bloc depuis le cache vers le disque, cette technologie est utilisée pour permettre l'écriture des blocs de méta-données du journal.

Les blocs de description sont des blocs du journal qui décrivent les autres méta-données du journal. Ce sont des blocs qui servent à savoir où le contenu des blocs de méta-données du journal doivent aller. Ce sont donc des blocs qui permettent de gérer la correspondance entre le journal et la structure du système de fichiers.

Pour finir, le fichier journal contient un certain nombre de blocs d'en-têtes à des positions précises. Ceux-ci enregistrent la position actuelle de la tête du journal, et de sa queue. Ils permettent donc de déduire les parties du journal qui ont été validées sur le disque (donc à jour) et les parties du journal encore non validées (uniquement présentes dans le journal, mais pas encore dans le système de fichiers).


5.2.3.3 Fonctionnement du journal

À un moment donné, soit parce que le système a attendu assez longtemps depuis sa dernière validation, soit parce que la place allouée au journal est presque totalement occupée, il va falloir valider les opérations présentes dans le journal. Une fois qu'elles ont été validées, les données ne sont pas encore synchronisées entre les blocs de données du système, et le contenu du journal. Les opérations qui suivent sont alors les suivantes :

Quand on est sûr que l'ensemble des données est bien écrit sur le disque, on peut libérer l'espace utilisé par le journal pour y mettre de nouvelles entrées.


5.2.3.4 État d'avancement et perspectives

Le travail sur ce système de fichiers est encore en cours. Les spécifications sont assez stables, et il n'y aura sans doute que peu de révisions majeures dans celles-ci. Cependant, l'implémentation est encore en cours, et le code ne doit donc pas être déjà considéré comme exploitable sur une machine autre qu'une machine de test ou de programmation.

Une fois que le code de base sera stable et figé, cette conception pourra prendre d'autres voies. Une des priorité des développeurs reste la performance de leur système de fichiers. Il faudra alors étudier l'impact réel de l'ajout de la journalisation sur le système ext2, en terme de performances, et rechercher les possibilités de les améliorer. Une autre piste d'amélioration consiste à ne pas écrire autant de données dans le journal, et par conséquent à diminuer sa taille, et augmenter ses performances. D'autres améliorations, comme le support de serveurs NFS rapides directement dans le système de fichiers, pourraient être envisagées.

Pour finir, le développement des outils associés à ce système de fichiers devrait pouvoir permettre, en raison de sa compatibilité avec ext2, de faire migrer un système existant (en ext2) vers un système journalisé (en ext3), d'une manière assez transparente pour l'utilisateur, c'est à dire, sans avoir à reformater le système de fichiers existant.


5.2.4 Les autres systèmes

Les systèmes de fichiers journalisés présentés dans les chapitres précédents sont les systèmes les plus avancés lors de l'écriture de cette étude. Cependant, d'autres systèmes sont en cours d'élaboration, et possèdent des caractéristiques similaires.


5.2.4.1 JFS de IBM

Le système JFS est le système de fichiers journalisé utilisé sur leurs systèmes d'exploitation AIX et OS/2. IBM a décidé de le publier sous la licence GPL au début de l'année 2000, dans l'objectif de le voir porté sous Linux. Une équipe de développeurs de IBM y travaille, et l'ouverture du code source et de la licence permettent à la communauté du logiciel libre de participer activement au portage sous Linux. Ce projet est donc très récent sous Linux, et le système n'est pas encore exploitable, même en phase bêta. En effet, seules quelques parties des fonctionnalités de bases du système de fichiers ont été implémentées. Seules les personnes souhaitant s'investir dans le développement du système sont invitées à l'expérimenter. Ce n'est que récemment qu'il est possible de créer un fichier et de l'effacer. De plus, ce système de fichiers ne différencie pas encore les majuscules des minuscules dans les noms de fichiers.

Les caractéristiques de ce système sont celles d'un système de fichiers journalisé. Le système peut donc redémarrer très rapidement après un incident. De plus, il est basé sur le fonctionnement des gestionnaires d'unités logiques (voir le chapitre correspondant au Linux Volume Manager pour plus d'informations), ce qui lui donne une souplesse intéressante au niveau du redimensionnement des partitions actives. L'état d'avancement du projet ne permet pas encore d'avoir une bonne idée des caractéristiques précises qu'il offrira sous Linux.


5.2.4.2 LinLog

Ce projet a débuté en mars 1998. Bien qu'il ait été commencé il y a un certain temps, il n'est pas actuellement totalement implémenté. Il a été initié par un étudiant, pour sa thèse. Cependant, à la fin de celle-ci, le projet a été mis en sommeil pendant plusieurs mois. L'employeur de l'auteur principal de ce système a décidé de sponsoriser partiellement le projet, ce qui a permis un redémarrage fin 1999.

L'approche de ce système de fichiers journalisé est assez similaire de l'approche de systèmes utilisés sur d'autres systèmes d'exploitation tels que Sprite LFS ou 4.4BSD LFS. Une grosse étude théorique sur les systèmes journalisés a été faite, et présente la journalisation des systèmes de fichiers d'une manière très complète.

L'état d'aboutissement de ce système est beaucoup plus avancé que le précédent. En effet, même s'il n'est pas encore complètement fonctionnel, les étapes restantes montrent bien que le projet s'approche d'une phase de correctif de bugs, et de fin d'implémentation de nouvelles fonctionnalités. Cependant, il n'offre pas de caractéristiques particulièrement remarquables par rapport aux projets plus avancés, tels que XFS ou ReiserFS.


[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