[Abstract] [Copyright Notice]

Étude sur l'évolution des systèmes de fichiers - Chapitre 1
Concepts de base


1.1 Le rôle du système de fichiers

Le rôle du système de fichiers est d'offrir une interface permettant de manipuler le concept de fichier. Ce concept est assez large sous Linux (et les Unix-like en général), puisqu'il concerne en effet :

La relation entre le système de fichiers et le noyau est par conséquent très étroite. Tous les accès standard aux périphériques (hormis les périphériques réseaux) passent par leur représentation sous forme de fichiers, et c'est le noyau qui s'occupe de traduire la requête faite sur le fichier en requête compréhensible par le périphérique proprement dit.

Dans cette étude, nous nous intéresserons plus particulièrement aux fichiers destinés à contenir des données pour les utilisateurs, mais il faut garder en tête les différents aspects que peuvent prendre les fichiers.

On résumera donc le rôle du système de fichiers comme interface d'abstraction permettant de manipuler le concept (assez large) de fichiers.


1.2 Représentation des fichiers

Le système de fichiers décompose le fichier vu par l'utilisateur en données brutes (celles auxquelles l'utilisateur accédera directement), et en méta-données (données internes permettant d'accéder aux données brutes). Ces méta-données sont complètement invisibles pour l'utilisateur, bien que leur rôle soit fondamental. Ce dernier est de stocker des informations telles le positionnement sur le média du contenu de tel ou tel fichier, ou encore de spécifier les permissions associées à un fichier.

La représentation d'un fichier, interne au système, est donnée par ce que l'on appelle un "inode". Ce mot, d'origine anglo-saxonne, est la contraction des mots "index" et "node". Sa traduction en français pourrait être "noeud d'index". Cet inode contient une description de l'aspect des données des fichiers, ainsi que des informations complémentaires, telles que le propriétaire, les droits d'accès ou encore les dates d'accès au fichier. Chaque fichier présent sur le disque possède un inode, mais il peut avoir plusieurs noms, qui se réfèrent tous à cet inode. Chaque nom est alors un lien (hard link). Quand un processus se réfère à un fichier par son nom, il va le décomposer en répertoires et en nom de fichier. Il va ensuite vérifier que le processus a le droit d'accéder à chacun des répertoires, et éventuellement récupérer l'inode du fichier. Quand un processus crée un nouveau fichier, le noyau lui assigne donc un inode libre (non utilisé). Pour ce faire, il regarde sa table des inodes libres, en choisi un, l'enlève de la table, ajoute une référence à cet inode, et remplit les informations contenues dans l'inode. La table des inodes libres fait partie de ce que l'on a appelé les méta-données.

La structure même du fichier sur le disque est décomposée en différents blocs. L'inode précédemment décrit contient une sorte de table des matières permettant de localiser les données d'un fichier sur le disque. Puisque chaque bloc de données du disque est adressable par un numéro, cette table des matières contient des ensembles de blocs disques. Cependant, plusieurs problèmes peuvent alors se poser. Si on suppose que chaque fichier est composé de blocs contigus sur le disque, le bloc de départ, ainsi que le la taille du fichier sont suffisants pour accéder à l'ensemble des données du fichier. Cependant, cette supposition n'est pas valide. Il devient alors très difficile de gérer l'augmentation de la taille des fichiers. En effet cette table des matières permet d'accéder directement à un certain nombre de blocs de données. On appelle celà l'adressage direct. On peut donc répartir les données du fichier sur des blocs indépendants du disque, l'inode pourra accéder directement à ces données. Pour limiter la taille de l'inode (il a une taille maximale fixée), il peut faire référence à un bloc d'une manière directe, indirecte simple, double ou triple. Cela permet d'avoir des fichiers stockés sur plus de blocs disques que l'inode ne peut directement en référencer. L'inode pointe alors, dans le cas d'un bloc indirect simple, sur une liste de numéros de blocs dans lesquels les données du fichiers sont présentes. Dans le cas du bloc indirect double ou triple, la référence de l'inode pointe sur une liste, qui pointe à son tour sur une liste de blocs (dans le cas double) et qui pointe encore sur une troisième liste (dans le cas triple). Cela permet d'avoir des inodes d'une taille raisonnable, mais pouvant référencer d'assez gros fichiers. C'est l'adressage indirect. (Voir figure).

Fondamentalement, un répertoire est un fichier comme un autre. Il permet simplement de hiérarchiser la représentation des différents fichiers. En effet, au lieu que l'inode représentant le répertoire contienne des pointeurs vers des blocs de données comme dans le cas d'un fichier de données, il contient des pointeurs vers d'autres inodes, associés aux noms des fichiers représentés dans ces répertoires. Le principe de double ou de triple adressage présenté dans le cas des gros fichiers, est encore valable ici pour des répertoires contenant beaucoup de fichiers.


1.3 Le système de fichiers ext2

Le système de fichiers ext2 est le système de fichiers standard de Linux. Il a été écrit à partir du système de fichiers ext1 qui était lui-même basé sur le système de fichiers Minix. Devant un manque de performances, et des fonctionnalités très limitées, l'auteur a voulu écrire un système stable, performant et extensible.


1.3.1 Fonctionnalités standard

Les fonctionnalités standard de ext2 permettent d'accéder à des partitions de 4 Tera-octets (1 Tera-octets = 1024 Giga-octets), alors que la version ext1 ne permettait que des partitions de 2 Giga-octets (1 Giga-octets = 1024 Méga-octets). La taille maximale des fichiers avec un système ext2 standard est de 2 Giga-octets. Les noms de fichiers sont limités à 255 caractères. De plus, lors de la création du système de fichiers, le système réserve une certaine quantité d'espace pour le super-utilisateur (root), en général 5%. Ceci permet au super-utilisateur de pouvoir se logger sur le système, et de faire des tâches administratives quand le système de fichiers est plein pour les utilisateurs. L'ensemble de ces fonctionnalités standard correspond aux fonctionnalités que l'on trouve en général sur d'autres systèmes Unix.


1.3.2 Fonctionnalités avancées

Les fonctionnalités avancées sont celles qui sont en général absentes des systèmes de fichiers Unix traditionnels, et sont en quelque sorte des extensions des systèmes de l'époque. Certaines d'entres elles sont néanmoins présentes sur bon nombre d'Unix modernes.


1.3.2.1 Attributs étendus

Il est possible d'utiliser des attributs particuliers sur des ensembles de fichiers. Le comportement du noyau se fera en fonction de ces attributs. De plus, si des attributs particuliers sont mis sur un répertoire, les fichiers créés dans ce répertoire hériteront des attributs du répertoire. Parmi ces attributs, on trouve par exemple, la possibilité de forcer l'effacement sécurisé d'un fichier. Dans ce cas, des données aléatoires seront écrites sur les blocs contenant les données du fichier, avant d'être dé-référencés dans les inodes. Il est également possible de verrouiller complètement un fichier tel qu'il se trouve. On ne peut alors pas ajouter de caractères, l'effacer, le déplacer, le renommer ou créer de nouveaux liens durs. La seule méthode pour modifier le fichier est alors de dé-valider cet attribut. On peut aussi obliger l'ajout d'informations dans le fichier, sans possibilité de l'effacer ou de modifier les données déjà présentes, tant que l'attribut est validé. Mais dans l'ensemble, ces attributs sont assez peu utilisés.


1.3.2.2 Sémantique

Il est également possible de pouvoir préciser, au moment du montage du système de fichiers, si on veut utiliser la sémantique BSD ou la sémantique System V R4 sur ce système de fichiers. Cela correspond, dans le cas BSD à définir que tous les fichiers (et sous-répertoires) créés dans un répertoire auront le même GID que le répertoire parent. La sémantique System V R4 est quant à elle un peu plus complexe. On peut en effet forcer le GID des fichiers et des sous répertoires d'un répertoire en lui plaçant le bit Set-GID. Les nouveaux sous-répertoires auront alors également le bit Set-GID de placé. Dans le cas où il n'est pas placé, le GID des fichiers et répertoires sera celui du processus créateur de ces fichiers ou répertoires.

Il est aussi possible, lors de la création du système de fichiers proprement dit, de préciser la taille des blocs à utiliser. Il faut se souvenir que cette taille sera la plus petite taille adressable sur le disque. Elle est fixée en général à 512, 1024, 2048 ou 4096 octets.

Une fonctionnalité importante, présente sur la majorité des systèmes de fichiers des Unix-like d'aujourd'hui, est une surveillance de son état. Quand un système de fichiers est monté en lecture/écriture, il est marqué comme étant "non-clean", soit non-propre. Quand il est démonté, ou remonté en lecture seule, il est marqué en tant que "clean". De plus, si le noyau le trouve dans un état différent des précédents, il le marque comme étant erroné. C'est cette fonctionnalité qui permet de lancer une vérification automatique de l'intégrité du systèmes de fichiers lors de son montage. Afin d'avoir une intégrité permanente, il est vérifié régulièrement à l'aide d'un compteur de montage. Une fois que le système de fichiers a été monté le nombre de fois spécifié dans ce compteur, il sera marqué "non-clean", et sera donc vérifié au montage suivant.


1.3.3 Structure physique

La structure physique de ext2 a été largement inspirée par le système de fichiers présent sur les systèmes BSD (FFS). En effet, il est constitué de groupes de blocs (littéralement blocks groups) qui ressemblent aux groupes de cylindres du FFS, à la différence que ext2 ne choisit pas la taille des groupes en fonction de la taille des cylindres du disque dur sous-jacent, pour permettre une abstraction totale du périphérique.

Le système est donc constitué de N groupes de blocs, présents après le secteur de boot du système de fichiers. Chacun de ces groupes possède la même structure, et possède une copie redondante des informations vitales du système de fichiers. Ces informations sont stockées dans les blocs intitulés "superblock" et "FS Descriptors". On trouve ensuite la carte des blocs du groupe (Block Bitmap), la carte des inodes du groupe (Inode Bitmap), la table des inodes, et enfin les blocs de données dans lesquels sont stockés le contenu des fichiers. (Voir figure)

Ce principe de groupes de blocs possède plusieurs avantages. Tout d'abord, du point de vue de la sécurité, il permet, par exemple, de récupérer un système de fichiers dont le superblock a été corrompu. La redondance des informations vitales du système permet de repérer une corruption de ces informations qui ne pourrait pas être facilement détectable autrement. Ensuite, du point de vue des performances, cela permet d'avoir une proximité permanente des informations vitales du système de fichiers, ce qui raccourcit le déplacement nécessaire des têtes de lectures pour y accéder.


1.3.4 Lacunes de ext2

Bien qu'ayant été conçu de façon intelligente, ce système de fichiers possède des limites inacceptables pour des machines nécessitant une disponibilité importante. Le temps de vérification du système de fichiers est proportionnel à sa taille, puisque le système va lire tous les inodes et vérifier leurs cohérences. Par conséquent, plus le système de fichiers est important, et plus cette vérification est longue. De plus, un crash peut détruire, ou rendre inaccessibles des données pourtant déjà présentes sur le disque.

Une autre limitation importante vient de l'absence d'ACL (Access Control Lists soit listes de contrôle d'accès) utilisées au niveau du système de fichiers, de manière native par Linux. La présence d'ACL permet en effet de gérer de manière très fine les droits d'accès aux fichiers.

On peut donc considérer que ces aspects sont les caractéristiques qui vont permettre la création de nouveaux systèmes de fichiers. Afin de maintenir la plus haute disponibilité possible, ceux-ci devront permettre de redémarrer rapidement après un arrêt brutal, dans un temps qui n'est pas en relation directe avec leur taille. De plus, les coûts de maintenance de ces systèmes devront être les plus faibles possibles, autant au niveau du temps qu'au niveau des ressources matérielles. Le principal problème rencontré aujourd'hui reste la sauvegarde des données du système de fichiers. En effet, si on veut effectuer une sauvegarde rigoureuse du système de fichiers, il faut fixer une date précise à laquelle le système de fichiers sera sauvegardé. Cependant, cette opération n'étant pas instantanée, la modification de ce dernier durant la sauvegarde peut conduire, dans certains cas, à une incohérence de fichiers entre eux. La meilleure solution serait d'arrêter le système de fichiers pour effectuer la sauvegarde, ce qui n'est pas acceptable dans la plupart des cas. Il faudrait donc pouvoir figer l'aspect du système de fichiers, sans empêcher les utilisateurs de travailler dessus. Cette solution peut également apporter la fonctionnalité de pouvoir "défaire" une opération malencontreuse, comme un effacement accidentel d'un fichier, ou l'écrasement d'un fichier par un autre. Ensuite, il sera sans doute très utile de pouvoir redimensionner la taille du système de fichiers d'une manière souple, donc non-destructive.

Il reste également l'aspect de la confidentialité des données des utilisateurs sur le système de fichiers. Il faudrait qu'une personne ayant un accès physique sur le média ne soit pas capable de pouvoir reconstituer l'ensemble des données présentes sur ce dernier.


[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