Systèmes de Gestion de Fichiers.
Réponse AJAX

Qu'est-ce qu'un système de gestion de fichiers

Voilà, notre voyage dans le monde des systèmes d'exploitation va se terminer avec cette séquence consacrée aux fichiers. Au niveau de chaque OS, nous avons mis en avant la notion de système de gestion de fichiers (SGF) également appelé, tout simplement, système de fichiers. En effet, il est primordial qu'un OS offre la possibilité, à un utilisateur, de sauvegarder ou lire ses documents, d'installer des fichiers exécutables associés à des applications ou des utilitaires, de gérer des fichiers de configuration ou encore des bibliothèques de fonctions. Nous avons vu dans les pages précédentes du support qu'il s'agit en fait à chaque fois de manipuler des fichiers placés dans des répertoires (dossiers), le tout placé sur un support de masse (Disque dur, Disquette, Clé USB, CD-ROM). Quand on emploie le terme « manipuler », il faut comprendre que l'on souhaite pouvoir stocker les fichiers mais également pouvoir les récupérer dans de bonnes conditions. Or le fait de pouvoir retrouver un fichier ou un répertoire nécessite d'être organisé un peu comme un bibliothécaire pour retrouver ses livres ou le marchand de journaux pour retrouver ses magazines. Cependant chacune de ces personnes a son propre système pour organiser les livres ou les magazines et bien, en informatique, il en va de même. Chaque OS ou du moins chaque concepteur d'OS essaye d'organiser les fichiers de la manière la plus efficace possible, la plus sûre et surtout en tenant compte de la capacité grandissante des supports magnétiques. C'est là qu'intervient la notion de « système de gestion de fichiers ». Il s'agit en fait d'un mécanisme logique, basé sur une ou plusieurs structures de données, permettant d'organiser l'espace physique d'un disque de façon à pouvoir y stocker des fichiers. Le mécanisme logique doit suffisamment être bien conçu et sans erreur pour permettre au mécanisme physique (le bras de lecture /écriture) de se positionner au bon endroit afin de récupérer ou écrire les octets du fichier et rien que du fichier.

Dans cette séquence nous allons expliquer le mécanisme du système de fichiers FAT16, FAT32 et Linux. Ces trois exemples sont suffisant pour avoir une idée de comment doit se débrouiller un OS pour gérer vos fichiers et répertoires. Aujourd'hui, l'évolution est plutôt tourner vers la sécurité des informations avec des permissions supplémentaires, sur la journalisation des actions effectuées sur les fichiers ou les répertoires de manière à pouvoir éventuellement retrouver un fichier dans un état convenable suite à l'arrêt brutal de l'ordinateur ou au plantage du système, la gestion des gros disques, minimiser la fragmentation possible des fichiers et surtout accélérer la rapidité d'accès à un fichier et à un répertoire, définir des quotas de disque pour chacun des utilisateurs et bien d'autres possibilités encore dans le cadre de l'administration des disques. A chaque fois, il est nécessaire d'ajouter des structures de données supplémentaires pour gérer ses différents éléments cités précédemment. C'est ce qui a amené par exemple Microsoft à évoluer de FAT32 à NTFS et à continuer à faire évoluer NTFS avec une structure de plus en plus complexe. C'est ce qui a amené LINUX à passer de ext2fs à ext3fs.

La notion de « cluster »

D'une manière générale, un système de gestion de fichiers est basé sur la gestion de clusters » ou « unités d'allocation ». Définissons ce terme. Un cluster est constitué d'un ou plusieurs secteurs consécutifs et est considéré par l'OS comme la plus petite unité de disque gérée. Le contenu d'un fichier est découpé, suivant sa taille, en un certain nombre de clusters (de blocs) qui seront placés sur le support magnétique (le disque) et répertoriés par le SGF. Ce dernier a donc pour rôle vital de savoir retrouver les clusters d'un fichier et c'est là que l'on retrouve différents mécanismes plus ou moins performants, plus ou moins limités, plus ou moins sécurisés comme FAT16, FAT32, NTFS, ext2fs, etc. Le nombre de secteurs par cluster dépend de l'OS, du système de gestion de fichiers utilisé mais aussi de la taille du disque ou de la partition considérée.

Un cluster appartient totalement à un fichier qu'il n'y ait qu'un seul octet à l'intérieur ou que le cluster soit totalement rempli. Ce principe engendre bien souvent de la perte de place surtout dans le cas où le nombre de secteurs par clusters est important. Prenons un exemple, supposons que notre système d'exploitation travaille avec des clusters de 32Ko soit 64 secteurs par clusters. Si on enregistre un fichier de 300 octets, un seul cluster suffit mais on peut voir qu'il y a beaucoup de perte de place. Si le SGF utilisé permet de travailler avec moins de secteurs pas cluster, on peut voir immédiatement que l'on a moins de perte. Vous pouvez alors vous dire mais pourquoi ne pas travailler directement avec des clusters d'une taille de 1 secteur ? Tout simplement parce que cela risque de faire beaucoup trop de clusters à gérer pour un fichier et donc une structure de données, associée au SGF, trop volumineuse qui risque alors d'occuper trop de place au détriment des fichiers. En effet, d'une manière générale, la structure de données associée à un SGF est là pour localiser les clusters qui appartiennent à un fichier. Plus il y a de clusters plus il faut mémoriser d'informations sur la position des clusters sur le disque afin de les retrouver lorsque cela est nécessaire. En regroupant plusieurs secteurs par cluster, il y aura un nombre moins important de clusters à gérer et donc une structure de données pour le SGF moins volumineuse. Par exemple, si j'ai un fichier de 500 Ko (512 000 octets), avec des clusters de 1 secteur il me faudra 1000 clusters. Avec des clusters de 32 Ko soit 64 secteurs, il ne me faudra plus que 16 clusters. En résumé, il faut mieux qu'un cluster regroupe plusieurs secteurs consécutifs même si cela engendre de la perte de place.

Les clusters d'un fichier ne sont pas forcément placés de manière consécutive sur le disque. En effet, l'OS est capable de repérer les clusters occupés, vides ou endommagés grâce à la structure de données du SGF. Ainsi lorsque l'on crée un nouveau fichier, l'OS va chercher, via le SGF, des clusters libres afin de les mettre à disposition du nouveau fichier. De même, lorsqu'on supprime un fichier, ses clusters sont remis à disposition du SGF. Plus on ajoute ou on supprime de fichiers, plus les clusters libres peuvent être éloignés les uns des autres ce qui a pour conséquence que les clusters associés à un fichier peuvent être éloignés les uns des autres. On parlera de fragmentation des fichiers d'où l'utilité parfois de défragmenter un disque afin de rapprocher les clusters associés au même fichier. La défragmentation permet d'accélérer le travail de l'OS lorsqu'il doit lire ou écrire dans les fichiers car cela permet de diminuer les déplacements de la tête de lecture/écriture du disque dur lors du parcours des clusters associés à un fichier.

Le système de gestion de fichiers de MS-DOS ou la FAT

Le système de gestion de fichiers FAT ou « Files Allocation Table » est le système de gestion de fichiers mis en avant par MS-DOS. Voici en quelques mots son principe de fonctionnement qui est simple, c'est pourquoi on en parle. Il permet de mieux comprendre les principes de fonctionnement d'un SGF et comment il doit se débrouiller pour retrouver les clusters associés à un fichier.

Juste un petit rappel avant de poursuivre. Le premier secteur d'une partition « primaire » ou « logique » s'appelle le secteur de boot. Il peut éventuellement contenir, dans le cas des partitions « bootables », un programme permettant d'installer en mémoire le noyau de l'OS en cours de démarrage. Attention, il ne faut pas confondre avec le MBR qui lui contient la description des partitions ainsi que le bootloader permettant de lancer l'exécution du programme se trouvant dans le secteur de boot.

Le secteur de boot contient également, en plus de l'éventuel programme de lancement de l'OS, que l'on appelle le programme de boot, des informations complémentaires sur la partition. Nous trouvons par exemple le nombre de secteurs par clusters, la taille d'un secteur en octet ou encore le nombre de FAT. Le système de gestion FAT tire son nom de la structure de données qu'il utilise. Cette structure de données est en fait une table (un tableau), appelée la « Table d'Allocation des Fichiers » ou « Files Allocation Table » ou « FAT », dans laquelle chaque entrée (chaque case) peut contenir une valeur numérique qui correspond en fait à un numéro de cluster. Cette structure de données est doublée afin d'avoir une sauvegarde en cas de problème. C'est pourquoi nous avons indiqué précédemment que l'une des informations complémentaires étaient le nombre de FAT. Comme nous venons de le dire, chaque entrée (chaque case) de la FAT peut contenir une valeur qui correspond à un numéro de cluster. Cette valeur est codée sur 16 bits d'où le terme de FAT16 souvent employé pour désigner ce système de gestion de fichiers. Avec des valeurs codées sur 16 bits, on peut représenter 216 valeurs différentes soit 65536. Cependant sur l'ensemble de valeurs possibles, certaines ne peuvent pas être utilisées car réservées à des codes particuliers de fonctionnement comme par exemple pour indiquer qu'un cluster est vide ou encore qu'un cluster est endommagé. Il reste en réalité 65525 valeurs possibles pour gérer les numéros de clusters. En résumé, la FAT est un tableau représentant un plan d'occupation des clusters de la partition concernée permettant de savoir quelles sont les clusters occupés par des fichiers, libres ou endommagés. Voici où nous en sommes pour l'instant.

Lors de notre cours sur MS-DOS et Windows, nous avons eu l'occasion de parler du répertoire principal désigné par le symbole « \ ». Ce répertoire constitue le point d'entrée de l'arborescence des répertoires. C'est pourquoi, juste après la FAT et sa copie, nous trouvons un espace réservé permettant de stocker le nom des fichiers et des sous-répertoires se trouvant à l'intérieur du répertoire principal. Chaque fichier ou sous-répertoire se trouvant dans le répertoire « \ » est notifié à l'intérieur de cette zone réservée par un ensemble de 32 octets, que l'on appelle une entrée de répertoire. Ces 32 octets se décomposent comme suit :

À partir de maintenant, nous avons tous les éléments nécessaires pour retrouver tous les clusters associés à un fichier ou à un répertoire. Toutefois, juste une précision avant de poursuivre. Lorsqu'un cluster est associé à un fichier, il contient les octets de ce dernier. Par contre, lorsqu'un cluster est associé à un sous-répertoire, il contient de nouveau des entrées sur 32 octets correspondant à la description des fichiers et des sous-répertoires de ce dernier. Ainsi de proche en proche, on retrouve le schéma de notre arborescence des répertoires vue dans les pages précédentes du support.

Dans les 32 octets associés à la description d'un fichier ou d'un répertoire, il y en a deux qui correspondent au numéro du premier cluster associé au fichier ou au répertoire. Que se passe-t-il si maintenant le fichier ou le répertoire se compose de plus d'un cluster ? Eh bien c'est simple. Le numéro du premier cluster correspond également à une entrée de la FAT portant le même numéro. A l'intérieur de cette entrée, on trouve une valeur qui peut être soit une valeur hexadécimale entre FFF8 et FFFF, indiquant qu'il n'y a pas d'autre cluster pour le fichier ou le sous-répertoire considéré, soit une autre valeur correspondant au numéro du cluster suivant. De nouveau pour savoir s'il y a encore une suite, il suffit de nouveau de regarder dans la FAT et d'interpréter la valeur de l'entrée portant le numéro du cluster trouvé précédemment et ainsi de suite. On parcourt un chaînage de clusters. Oulala, je vois quelques yeux s'arrondir ! Allez un petit schéma.

Remarque

Les entrées de la FAT sont numérotées dans l'ordre et à partir de 0. Les deux premières entrées sont réservées à la gestion de la FAT elle-même.


Pour simplierer la lecture du schéma, les valeurs 7 et 28 sont des valeurs données en base 10. En lisant les valeurs de la FAT avec un éditeur hexadécimal comme « Winhex », les valeurs seraient apparues en hexadécimale.

Remarque

Le répertoire principal est limité à 512 entrées. Par contre, les sous-répertoires ne sont pas limités sauf par la taille de la partition.

Justement, quelle est la taille de la partition qu'il est possible de gérer avec une FAT16 ?

La plus grande taille que l'on puisse utiliser pour un cluster est de 32768 octets (64 secteurs). Cela nous donne 32768 * 65525 = 2147123200 octets soit sensiblement 2Go. En conclusion, en FAT16, la limite d'une partition est de 2Go avec des clusters de 64 secteurs.

Remarque

Voilà nous venons de détailler le mécanisme de la FAT16. Pour les autres systèmes de gestion de fichiers, que nous allons voir dans la suite, nous n'irons pas aussi loin à chaque fois. L'essentiel était de voir au moins une fois comment un OS peut se débrouiller pour gérer fichiers et répertoires.

Le système de fichiers FAT32

À partir de Windows 95 OSR2, il a été mis en place le système de fichiers FAT32. Ce système a pour principe de fonctionnement le même principe de chaînage des clusters que nous venons de décrire au sujet de la FAT16. Cependant, les entrées de la structure FAT du système FAT32 acceptent des valeurs codées sur 32 octets (en fait 28 car les 4 octets de poids fort sont réservés). Cela offre une plus grande plage de valeurs possibles pour la numérotation des clusters. La FAT32 offre la possibilité théorique de prendre en charge des disques pouvant atteindre 2 Téraoctets. Remarque: Les outils de formatage de Windows XP place cette limite à 32Go. Pour aller au-delà, il faut passer par un utilitaire indépendant de XP.

Autre différence d'avec le système FAT16, c'est que le répertoire racine ne se trouve plus à la suite de la structure FAT, et de sa copie, mais que la liste des fichiers et sous-répertoires de ce dernier se trouve dans une liste chaînée de clusters exactement comme un fichier ou un sous-répertoire. Le premier numéro de cluster associé au répertoire principal (« \ ») se trouve spécifié dans la liste des informations complémentaires du secteur de boot. Il n'y a donc plus de limitation dans le nombre d'entrées possibles pour ce répertoire.

Le système FAT32 peut gérer un plus grand nombre de clusters que dans le cas de la FAT16 ce qui permet de diminuer le nombre de secteurs par cluster. En effet, dans le cas de la FAT16 comme on dispose d'un nombre limité de numéros possibles pour les clusters, on contourne la problématique en augmentant le nombre de secteurs par cluster ce qui permet, artificiellement, de pouvoir travailler avec des disques de plus grande capacité. Cependant, comme nous l'avons dit précédemment, plus il y a de secteurs par cluster, plus il y a de risque d'avoir une perte de place considérable. En diminuant le nombre de secteurs par cluster, la perte est moindre. Ainsi pour une partition de 2Go, nous passons de 64 secteurs par cluster en FAT16 à 8 secteurs par cluster en FAT32, on passe d'une taille de 32768 octets par cluster à 4096 octets. La différence de perte est notable.

La FAT32 autorise l'utilisation des noms longs pour les fichiers et les répertoires. Cependant, il a été conservé la notion de « nom court » (format 8.3) des fichiers et des répertoires pour garder une compatibilité avec les applications anciennes ne connaissant pas la notion de noms longs. Comment les noms longs et les noms courts (format 8.3) sont-ils gérés ?

Comme dans le cas de la FAT16, les clusters associés à des répertoires contiennent des entrées sur 32 octets pour chaque fichiers et sous-répertoires contenus dans ceux-ci (voir le paragraphe sur la FAT16). Cependant, en FAT32, il existe deux sortes d'entrées, les entrées « nom court » (« short directory entry ») et les entrées « nom long » (« long directory entry »).

Chaque entrée « nom court » contient les informations dont nous avons déjà parlé pour les entrées de répertoire de la FAT16. Ainsi, les 11 premiers octets contiennent la traduction du nom long, du fichier ou du répertoire considéré, en nom court, c'est à dire en format 8.3 (cf le paragraphe concernant le nom des fichiers et des répertoires avec MS- DOS précédemment dans ce support) et les autres octets contiennent la taille du fichier, ses attributs (caché, système, etc), le numéro du cluster de départ, les dates de création, de modification et de dernier accès.
Le nom long d'un ? chier est morcelé en fragments de 13 caractères qui sont ensuite placés chacun dans une entrée « nom long ». Les entrées « nom long » associées à un ? chier ou à un répertoire sont placées juste au dessus de l'entrée « nom court » de ce dernier.

Prenons un exemple avec un fichier de nom « Nom de mon fichier.txt ». A l'aide d'un utilitaire comme « Winhex » regardons le contenu des entrées du répertoire contenant ce fichier. Le nom long est composé de 22 caractères car il faut compter le point comme un caractère normal dans le cas des noms longs. Cela implique qu'il nous faut deux entrées « nom long » pour stocker ces caractères.

Remarque

Le nom court correspondant à notre exemple est « NOMDEM~1.TXT »

Voici les entrées que nous pouvons observer pour notre exemple :

Les entrées sont à lire du bas vers le haut à partir de l'entrée « nom court ». Ainsi, sur notre capture d'écran, nous trouvons l'entrée « nom court » avec les différentes informations spécifiques à une entrée de répertoire, puis la première entrée « nom long » et enfin la deuxième entrée « nom long ».

D'une manière générale, voici le descriptif des 32 octets d'une entrée « nom long » :
Numéro de l'octetDescription
0 Les entrées « nom long » sont placées dans l'ordre de création sachant que l'on ne peut stocker que 13 caractères par entrée « nom long ». Cet octet contient le numéro d'ordre de l'entrée « nom long ». Petite particularité, le bit n°6 de cet octet est placé à 1 lorsqu'il s'agit de la dernière entrée « nom long » associée au fichier ou au répertoire. Dans notre exemple, nous pouvons observer que cet octet porte la valeur hexadécimale « 01 » (soit 1 en décimale) pour la première entrée « nom long » et « 42 » pour la deuxième entrée « nom long ». Si nous traduisons en binaire la valeur hexadécimale 42, nous obtenons : 0100 0010. Le bit n°6 est à 1 donc il s'agit de la deuxième et dernière entrée « nom long » associée au fichier. Rappel: les bits sont numérotés de droite à gauche et à partir de 0.
1 à 10
(soit 10 octets)
Les noms longs utilisent le codage UNICODE des caractères qui code les caractères sur 2 octets. Ainsi 2 octets consécutifs correspondent à 1 caractère. Nous avons une séquence de 10 octets qui codent donc 5 caractères.
11Il contient la valeur hexadécimale « 0F » indiquant qu'il s'agit d'une entrée « nom long ».
12 et 13 2 octets réservés.
14 à 25
(soit 12 octets)
Contient les 6 caractères suivant du nom long.
26 et 27toujours à 0
28 à 31
(soit 4 octets)
Contient les 2 caractères suivant du nom long. Nous arrivons donc à un total de 13 caractères pour l'entrée considérée.

Traduisons les caractères de la première entrée « nom long » de notre exemple.

Remarque.

Les processeurs « Intel et compatibles » inversent les octets lors de la lecture d'un mot (2 octets consécutifs), il faut donc en tenir compte pour trouver la correspondance entre un code « UNICODE » et le caractère associé.

Traduisons les caractères de la deuxième et dernière entrée « nom long ».

Remarque

La fin d'un nom long est marqué par le caractère spécial NUL et les octets restants sont complétés par la valeur hexadécimale FFFF sauf, bien entendu, si la dernière entrée « nom long » est totalement remplie par 13 caractères.

Quelques mots sur NTFS

Avec la branche Windows NT et plus précisément avec Windows NT4, Microsoft a mis en place un nouveau type de système de gestion de fichiers de nom NTFS (New Technology File System). C'est un système plus complexe que le système FAT qui permet, entre autre, de :

Avec NTFS, la structure de données gérant les clusters des fichiers utilise un système sous forme d'arbre et non un système de liste chaînée ce qui permet d'accélérer les accès.

NTFS permet également à un administrateur d'appliquer des autorisations (des droits) sur un fichier ou sur un répertoire (dossier) à un utilisateur ou à un groupe d'utilisateurs. Pour cela, il suffit, à partir du poste de travail ou de l'explorateur de Windows, de cliquer avec le bouton droit de la souris sur le nom du fichier ou du répertoire (dossier) concerné puis prendre "Propriétés" dans le menu contextuel et enfin cliquer l'onglet "Sécurité" dans la boite de dialogue qui apparaît. Attention, si la partition, où se trouve le fichier ou le dossier, est en FAT32, l'onglet "Sécurité" n'apparaîtra pas.

Remarque

Par défaut, l'onglet Sécurité n'est pas visible en NTFS. Pour le faire apparaître, il faut aller dans le poste de travail, cliquer dans la barre de menu sur [Outils] [Options des dossiers], dans l'onglet « Affichage », et plus précisément dans la rubrique « Paramètres avancés », décochez l'option « Utiliser le partage de fichiers simple (recommandé) ». Ensuite, refaites la manipulation définie précédemment.

Ouvrons une petite parenthèse par rapport à Windows XP. Le fait d'avoir décoché l'option « Utiliser le partage de fichiers simple (recommandé) » a une autre conséquence. Vous vous souvenez, à la fin de la séquence 3 sur Windows XP, nous avons parlé des dossiers partagés. A ce moment là, nous avons indiqué que pour partager un dossier, il fallait aller dans le poste de travail, faire un click-droit sur le dossier à partager, prendre [Partage et sécurité] dans le menu contextuel puis cliquer l'onglet « Partage ». En fait, en ayant décoché l'option précédente, la boite de dialogue n'est plus identique à celle que nous avons mis en avant à ce moment là.

Cette boite de dialogue permet toujours de donner un nom de partage mais elle permet aussi d'apporter des éléments de sécurité sur le partage comme le nombre de personnes autorisées à se connecter simultanément sur le dossier partagé mais également donner ou retirer des autorisations de lecture et de modification, du contenu du dossier partagé, à certains utilisateurs ou à certains groupes d'utilisateurs. Cela se fait en cliquant sur le bouton « Autorisations » de la boite de dialogue. Nous refermons la parenthèse.

Remarque.

Il existe un outil permettant de convertir une partition FAT en partition NTFS. Il s'agit de l'outil « convert » fourni avec Windows.

Vous trouverez beaucoup d'information sur le principe des partitions NTFS sur Internet à partir du mot clé « NTFS ». Attention, les explications ne sont pas toujours simples car NTFS est plus complexe que les partitions FAT car il se compose de différentes types d'informations permettant de répondre aux besoins de rapidité, aux besoins de gérer de grosses partitions et de gros fichiers, aux besoins de sécuriser les accès aux fichiers et aux répertoires mais également aux besoins d'éviter les pertes de données.

Les systèmes de gestion de fichiers de UNIX / LINUX

Voici un autre mécanisme de SGF assez accessible. Pour commencer, nous allons décrire le mécanisme général du système de fichiers UNIX puis ensuite nous verrons les quelques différences d'avec le système ext2fs de Linux. Sous UNIX, le système de fichiers se compose de 4 parties.

  1. Le secteur de Boot contient éventuellement un court programme, le programme de boot, permettant l'amorçage de l'OS.
  2. Le Superbloc : Il contient des informations sur le « file system » lui-même, à savoir:
  3. La table des « inodes » appelée également la « ilist » : ce bloc contient un ensemble de structures de données particulières appelées « inode » pour « index node ». Un « inode » contient des informations sur un fichier ou un répertoire donné sauf son nom. Mais quelles sont les informations contenues dans un « inode » ? On y trouve :
  4. Les blocs de données : ces blocs contiennent soit les données d'un fichier ou d'un répertoire soit des numéros d'autres blocs dans le cas des indirections. Intéressons nous quelques instants au contenu des blocs de données associés à un répertoire. En fait, ces blocs contiennent une liste d'entrées constituées d'une association (Numéro de inode, nom de fichier ou de répertoire) et ce pour chacun des fichiers ou des sous- répertoires contenus dans le répertoire considéré. Les deux premières entrées sont les répertoires « . » et « .. ». Le numéro de inode associé à un nom de fichier ou de répertoire permet d'indiquer quel inode situé, dans la table de « inodes », contient le reste des informations notamment les permissions et les numéros de blocs de données associés. Voici un exemple de bloc associé à un répertoire :

Maintenant voyons comment marche ce mécanisme. Pour cela, prenons un exemple. Nous souhaitons trouver les blocs de données associés à un fichier de nom « MonFichier ». Comment allons-nous procéder ?

Pour commencer, nous recherchons, à l'intérieur des blocs de données associés au répertoire contenant le fichier de nom « MonFichier », le numéro d'inode associé à celui-ci. Une fois que ce numéro est repéré, il ne nous reste plus qu'à nous rendre dans la table des inodes afin de consulter les informations de l'inode portant ce numéro et nous obtenons ainsi les numéros des blocs de données du fichier « MonFichier ». Un schéma ? Très bien voilà.

Voilà, le mécanisme est très simple. Voyons ce qu'a ajouté LINUX avec le système de fichiers « ext2fs ». Son fonctionnement de fond est le même que ce que nous venons de décrire précédemment. Voyons les ajouts. En fait, une partition est découpée en groupes de blocs de même taille. L'idée des groupes de blocs est d'éviter que les blocs de données associés à un fichier ou à un répertoire ne soient trop éloignés les uns des autres afin d'améliorer les performances de l'OS. Chaque groupe de blocs se compose de six parties :

Remarque.

La table d'état d'allocation des inodes du groupe représente une cartographie binaire des inodes du groupe permettant ainsi de repérer l'emplacement des inodes libres et des inodes occupés. Pour ce faire, chaque inode est repéré dans la table par un bit. Ce bit vaut 0 si l'inode considéré est libre et 1 s'il est occupé. On parle parfois de table « bitmap ». La table d'état d'allocation des blocs du groupe fonctionne sur le même principe permettant ainsi de savoir où se trouvent les blocs libres et les blocs occupés.

Cela nous donne

Le superbloc et la liste des descripteurs de groupe sont répétés au début de chaque groupe car ce sont les éléments importants sur la structure de la partition. En les dupliquant, il est toujours possible de récupérer les informations nécessaires sur un autre groupe de blocs.

Remarque

Le système ext3fs qui est le successeur de ext2fs a apporté, comme dans le cas de NTFS, la journalisation des opérations effectuées sur le « file system » mais fonctionne comme ext2fs.