Module 3 : Systèmes de fichiers et gestion des E/S

Un système de fichiers est l’interface logicielle qui permet d’organiser, de stocker et de retrouver des données sur un support de stockage persistant
(disque dur, SSD). Son rôle va bien au-delà du simple rangement : il doit garantir l’intégrité des données face aux pannes, optimiser les
performances d’accès à un matériel lent, et offrir des fonctionnalités avancées comme la journalisation, les instantanés ou le chiffrement. Ce cours
explore l’architecture et le fonctionnement interne des systèmes de fichiers modernes, en mettant l’accent sur les mécanismes de cohérence
(journaling), l’organisation des métadonnées, les stratégies d’ordonnancement des accès disque et la gestion des périphériques par le système
d’exploitation. Nous analyserons en détail des systèmes emblématiques comme ext4, NTFS, ZFS et Btrfs, en illustrant les compromis entre
performance, fiabilité et richesse fonctionnelle.
1. Journaling, Métadonnées, Pipes et Périphériques Blocs
1.1. Le problème de la cohérence et la solution du journaling
Lorsqu’une application modifie un fichier (par exemple, en ajoutant une ligne à un document), cette opération logique simple se traduit, au niveau
du disque, par plusieurs écritures physiques distinctes et non atomiques. Prenons l’exemple de la création d’un fichier : le système doit (1) marquer
un inode comme utilisé, (2) écrire les métadonnées de cet inode, (3) écrire le contenu du fichier dans des blocs de données, et (4) ajouter l’entrée
avec le nom du fichier dans le répertoire parent. Si une panne de courant survient après seulement deux de ces écritures, le système de fichiers se
retrouve dans un état incohérent : par exemple, un inode pourrait être marqué comme "utilisé" sans qu’aucun répertoire n’y fasse référence (fuite
d’espace), ou un répertoire pourrait pointer vers un inode non initialisé.
Pour résoudre ce problème critique, les systèmes de fichiers modernes utilisent une technique de journalisation (journaling), inspirée des bases de
données transactionnelles. Le principe est d’écrire d’abord, dans une zone séquentielle du disque appelée journal (ou log), un enregistrement
décrivant toutes les modifications que l’on s’apprête à effectuer. Ce n’est qu’une fois cette "intention" solidement écrite sur le disque que les
modifications sont appliquées à leur emplacement définitif dans le système de fichiers principal. En cas de crash, le processus de récupération est

1
simple et rapide : il suffit de lire le journal et de rejouer (replay) les transactions complètes, ou d’ignorer celles qui étaient incomplètes. Cela élimine
le besoin d’une longue vérification complète du disque et garantit un temps de redémarrage court et prévisible.

Il existe plusieurs niveaux de journalisation, offrant un compromis entre sécurité et performance :

• Journaling complet (data=journal) : Les données et les métadonnées sont journalisées. C’est le mode le plus sûr, mais aussi le plus lent
en écriture, car toutes les données sont écrites deux fois.
• Journaling ordonné (data=ordered - défaut sur ext4) : Seules les métadonnées sont journalisées. Cependant, le système garantit que les
blocs de données correspondants sont écrits physiquement sur le disque avant que la transaction de métadonnées ne soit marquée comme
validée dans le journal. Ce mode protège contre la corruption des métadonnées et empêche l’apparition de "données anciennes" dans un
fichier après un crash.
• Journaling des métadonnées (data=writeback) : Seules les métadonnées sont journalisées, sans garantie sur l’ordre d’écriture des
données. C’est le mode le plus rapide, mais il peut entraîner, dans de rares cas, l’apparition de données non récentes dans un fichier après
une panne.

1.2. Les métadonnées : le squelette du système de fichiers

Les métadonnées sont les données qui décrivent les données. Elles constituent l’ossature qui donne un sens à la simple suite de blocs binaires
stockés sur le disque. La structure centrale est l’inode (index node). Chaque fichier et répertoire possède un inode unique qui contient toutes ses
informations, à l’exception de son nom. Un inode typique (comme dans ext4) contient :

- Le type du fichier (régulier, répertoire, lien symbolique, etc.) et ses permissions d’accès (read, write, execute).
- L’identifiant du propriétaire (UID) et du groupe (GID).

2
 - Les horodatages (atime : dernier accès, mtime : dernière modification, ctime : dernière modification des métadonnées).
- La taille du fichier.
- La carte pointant vers les blocs de données réels sur le disque. Pour les petits fichiers, les adresses sont stockées directement dans l’inode
(pointeurs directs). Pour les fichiers plus volumineux, l’inode pointe vers des blocs d’indirection (simple, double ou triple) qui contiennent
eux-mêmes des listes d’adresses.

Le nom du fichier, lui, n’est pas stocké dans l’inode. Il est enregistré dans l’entrée de répertoire du parent. Un répertoire est essentiellement un
fichier spécial dont le contenu est une table associant des noms de fichiers à des numéros d’inode. Cette séparation permet d’avoir plusieurs noms
(liens physiques) pointant vers le même inode, et donc les mêmes données.

1.3. Pipes et Périphériques Blocs

Les pipes sont un mécanisme fondamental de communication inter-processus. Ils permettent à la sortie standard (stdout) d’un processus de devenir
l’entrée standard (stdin) d’un autre. Une pipe anonyme (créé par l’appel système pipe()) existe uniquement en mémoire et est typiquement utilisé
entre un processus parent et son enfant. Une pipe nommée (ou FIFO, First In, First Out), créé avec la commande mkfifo, apparaît comme un fichier
spécial dans le système de fichiers. Tout processus, même sans relation de parenté, peut alors l’ouvrir en lecture ou en écriture, permettant une
communication asynchrone et structurée.

Les périphériques blocs (/dev/sda, /dev/nvme0n1) représentent l’abstraction matérielle des supports de stockage. Contrairement aux périphériques
caractères (comme le clavier /dev/input) qui gèrent des flux d’octets, les périphériques blocs permettent des accès aléatoires par blocs de taille
fixe (souvent 512 octets ou 4 kb). Le système de fichiers construit ses structures logiques (inodes, répertoires) sur cette abstraction. Le noyau utilise
des mémoires tampons (buffers) et des caches sophistiqués pour optimiser ces accès : les lectures remplissent un cache en mémoire vive, et les
écritures y sont souvent temporisé avant d’être regroupées et écrites de manière optimale sur le disque physique.

3
 2. Systèmes de fichiers modernes : ext4, NTFS, ZFS, Btrfs
2.1. ext4 : La référence de la stabilité sous Linux
ext4 (Fourth Extended Filesystem) est l’évolution mature de la lignée ext, conçue pour la stabilité, la compatibilité ascendante et des performances
robustes. C’est le système de fichiers par défaut de la plupart des distributions Linux. Ses innovations majeures par rapport à ext3 sont :
▪ Les extents : Ils remplacent le schéma traditionnel de blocs indirects. Un extent est une paire (adresse_de_début, longueur) qui décrit une
séquence contiguë de blocs. Pour un fichier volumineux (comme une vidéo), ext4 peut ainsi le décrire avec une poignée d’extents au lieu
de milliers d’adresses individuelles, réduisant la fragmentation et la charge des métadonnées.
▪ L’allocation retardée (delayed allocation) : Lorsqu’un processus écrit des données, ext4 les garde en mémoire cache le plus longtemps
possible, en retardant la décision sur l’emplacement physique définitif des blocs. Cela permet au système de voir arriver plus de données
et de choisir, in fine, un espace contigu optimal sur le disque, améliorant significativement les performances des écritures séquentielles.
▪ Le journaling via JBD2 : Il utilise une couche de journaling générique, fiable et performante, typiquement en mode "ordonné".
ext4 excelle comme système généraliste pour les partitions racine (/) des serveurs et postes de travail, là où la fiabilité éprouvée prime sur des
fonctionnalités expérimentales.

2.2. NTFS : Le système polyvalent de Windows

NTFS (New Technology File System) est le système natif de Microsoft Windows. Sa force réside dans sa riche fonctionnalité orientée entreprise
et sa gestion fine de la sécurité. Sa structure centrale est la Master File Table (MFT), une table extensible où chaque entrée de taille fixe décrit un
fichier ou un répertoire. Pour les très petits fichiers, le contenu peut être stocké directement dans l’entrée MFT (resident data), rendant l’accès
extrêmement rapide.
Ses caractéristiques notables incluent :
• Journaling partiel (principalement pour les métadonnées) via son Log File Service.
• Des listes de contrôle d’accès (ACL) très granulaires pour des permissions complexes.

4
 • Le chiffrement transparent au niveau fichier (EFS).
• Les flux de données alternatifs (Alternate Data Streams), permettant d’attacher des métadonnées invisibles à un fichier (comme l’origine
d’un téléchargement).
• Les points d’analyse (reparse points), utilisés pour les liens symboliques, les points de montage ou les dossiers compressés.
2.3. ZFS : La forteresse de l’intégrité des données
Conçu à l’origine par Sun Microsystems, ZFS adopte une philosophie radicale : il fusionne le gestionnaire de volume physique et le système de
fichiers logique en une seule couche cohérente, éliminant de nombreux problèmes traditionnels. Ses piliers sont :
o Le modèle Copy-on-Write (CoW) transactionnel : Jamais les données existantes ne sont modifiées sur place. Toute mise à jour crée de
nouveaux blocs. Une fois l’opération complètement écrite, un pointeur racine est atomiquement basculé vers cette nouvelle version. Cela
supprime le besoin d’un journaling séparé et rend les instantanés (snapshots) instantanés, légers et parfaits.
o L’intégrité de bout en bout : Chaque bloc (données et métadonnées) est protégé par un checksum. Ce checksum est stocké non pas avec
le bloc lui-même, mais dans le pointeur du bloc parent. Ainsi, toute lecture permet de vérifier l’intégrité. Si une corruption silencieuse est
détectée et que le pool de stockage est en mode redondant (miroir ou RAID-Z), ZFS peut auto-réparer (self-healing) la donnée en utilisant
la copie saine.
o Les pools de stockage (zpools) : L’espace est agrégé à partir de plusieurs disques physiques. Sur ce pool, on crée des systèmes de fichiers
(datasets) qui partagent dynamiquement l’espace disponible, évitant le gaspillage des partitions de taille fixe.
o La compression, la déduplication et le RAID-Z (une implémentation RAID logicielle plus intelligente et résistante aux corruptions).
ZFS est le choix par excellence pour les serveurs de données, les NAS et tout environnement où l’intégrité absolue et les fonctionnalités de stockage
avancées sont critiques. Sa licence (CDDL) peut poser des questions de compatibilité pour son intégration directe au noyau Linux, mais il est
disponible via des modules ou le projet OpenZFS.
2.4. Btrfs : La flexibilité et la modernité sous Linux

5
Btrfs (B-tree File System) est la réponse de la communauté Linux, partageant la philosophie CoW de ZFS mais conçue nativement pour le noyau
Linux. Comme ZFS, il utilise des arbres-B pour toutes ses structures et applique des checksums sur toutes les données et métadonnées. Sa grande
force est la flexibilité via son architecture en sous-volumes :
Copy-on-Write :
Contrairement aux systèmes journalisés (comme ext4) qui écrivent par-dessus les anciennes données et utilisent un journal pour se remettre d'un
crash, la philosophie CoW fonctionne différemment :
1. Écriture sécurisée : Lorsque des données doivent être modifiées, le système ne les écrase pas. Il écrit les nouvelles données dans un nouvel
emplacement libre sur le disque.
2. Mise à jour atomique : Une fois l'écriture terminée et vérifiée, le système met à jour les pointeurs (l'index) pour qu'ils référencent ce nouvel
emplacement.
3. Libération de l'ancien espace : L'ancien bloc de données est alors marqué comme libre et peut être réutilisé plus tard
• Un sous-volume Btrfs n’est pas une partition physique séparée, mais un point de montage logique au sein d’un même pool de stockage. Il
peut avoir ses propres limites (quotas) et être snapshoté indépendamment.
• Cela permet des scénarios puissants : un sous-volume pour le système (/), un autre pour les données utilisateurs (/home). On peut prendre
des instantanés fréquents et légers du premier sans impacter le second, et les envoyer à distance de manière efficace.
• Fonctionnalités intégrées : Compression transparente (zstd, lzo), RAID logiciel (0, 1, 10), et outil de vérification/réparation (btrfs scrub).
Btrfs est idéal pour les postes de travail avancés, les serveurs nécessitant une gestion flexible de l’espace et des sauvegardes instantanées, et comme
système de fichiers racine pour des distributions comme SUSE Linux Enterprise ou Fedora.

6
Tableau comparatif :

Critère ext4 NTFS ZFS Btrfs

Fonctionnalités riches
Philosophie Stabilité, compatibilité Intégrité absolue, entreprise Flexibilité, fonctionnalités modernes
(Windows)

Mécanisme Copy-on-Write, pools, Copy-on-Write, sous-volumes,

Journaling, extents Journaling, MFT, ACL
clé checksums E2E checksums

Via VSS (Volume Shadow

Snapshot Non natif Oui, instantané, léger, parfait Oui, instantané, léger
Copy)

Système Linux Serveurs, NAS, stockage Postes de travail avancés, serveurs

Cas d'usage Systèmes Windows
généraliste critique flexibles

3. Ordonnancement disque, Caches et Buffers

3.1 L’ordonnancement des E/S disque

Les disques durs mécaniques (HDD) ont une faiblesse majeure : la latence due au déplacement des têtes de lecture/écriture (seek time) et à
la rotation du plateau (rotational latency). L’ordonnanceur d’E/S (I/O scheduler) du noyau a pour mission de réorganiser les requêtes en attente
dans les files d’attente pour minimiser ces mouvements physiques et maximiser le débit global.

• Algorithmes classiques :

7
 o CFQ (Completely Fair Queuing) : Tentait de répartir équitablement le temps d’accès entre les processus. Efficace pour les charges
de travail mixtes, mais pouvait nuire aux performances séquentielles.
o Deadline : Associe un "délai impératif" (deadline) à chaque requête pour éviter qu’une requête située loin sur le disque ne soit
indéfiniment reportée (famine). Excellent compromis pour les serveurs.
o NOOP (No Operation) : Ne réorganise pas les requêtes. Il les transfère dans l’ordre d’arrivée. Devenu pertinent pour les SSD où le
temps de recherche est quasi-nul.
• Algorithmes modernes :

o mq-deadline : Adaptation de Deadline pour l’architecture

o Kyber : Ordonnanceur basé sur la latence. Il tente de maintenir des latences de lecture et d’écriture prédictibles en adaptant
dynamiquement la profondeur des files d’attente. Très efficace pour les disques rapides.
3.2. Les caches et buffers du noyau
La différence de performance entre la RAM (nanosecondes) et le disque (millisecondes) est colossale. Le noyau utilise donc une partie de la
mémoire physique libre comme cache géant pour masquer cette lenteur.
• Page Cache : C’est le cache principal. Il stocke les pages mémoire (généralement de 4 KiB) correspondant aux blocs de données lus
depuis tous les systèmes de fichiers et les fichiers réguliers. Une seconde lecture des mêmes données sera servie instantanément depuis la
RAM.
• Buffer Cache (historique/intégré) : Initialement séparé pour les métadonnées des systèmes de fichiers, il est maintenant fusionné avec le
Page Cache. Son rôle conceptuel subsiste : optimiser l’accès aux blocs contenant des inodes, des bitmaps ou des entrées de répertoire.
• Écritures différées (Writeback) : Lorsqu’un processus écrit dans un fichier, les données sont d’abord copiées dans le Page Cache. Le
processus peut continuer son exécution immédiatement. Les pages modifiées ("sales" ou dirty) ne sont écrites sur le disque que plus tard,

8
 de manière asynchrone, par des threads noyau dédiés (flusher threads). Cela permet de regrouper de nombreuses petites écritures en
opérations plus grandes et séquentielles, bien plus efficaces sur disque.
• Synchronisation : garantir la persistance : Cette temporisation pose un problème pour les applications qui nécessitent une garantie de
persistance (bases de données, journaux système). Les appels fsync() (pour un fichier) et sync() (global) forcent l’écriture physique
immédiate de toutes les données "sales" associées, du cache vers le disque.
4. Gestion des Périphériques
4.1 L’abstraction « Tout est un fichier » et le répertoire /dev
La philosophie d’UNIX et de Linux de tout abstraire en fichier trouve son illustration parfaite dans la gestion des périphériques. Chaque composant
matériel (disque, port série, imprimante) ou virtuel (générateur de nombres aléatoires) est représenté par un fichier spécial dans le répertoire /dev.
• Périphériques caractères (c) : Accès en mode flux d’octets, séquentiel.
• Périphériques blocs (b) : Accès aléatoire par blocs de taille fixe. Exemples. Ce sont sur ces fichiers que les systèmes de fichiers sont
montés.
Ces fichiers ne contiennent pas de données en eux-mêmes. Ils sont des points d’entrée, des interfaces. Lorsqu’on lit ou écrit sur /dev/sda1, on
interagit directement, via le pilote (driver), avec la partition du disque. Les numéros majeur (identifiant de la classe de pilote) et mineur (identifiant
de l’instance) définis par ls -l /dev/sda permettent au noyau de router l’opération vers le bon code pilote.
4.2. La gestion dynamique et intelligente
Historiquement, /dev était peuplé statiquement de milliers de nœuds pour tous les périphériques imaginables, qui s’exécute en espace utilisateur, a
révolutionné cette gestion en peuplant /dev dynamiquement à la détection du matériel.
Lorsque le noyau détecte un nouveau périphérique (au démarrage ou à chaud, comme une clé USB), il envoie un événement (uevent) via un bus
virtuel (sysfs). Le démon udev reçoit cet événement et consulte un ensemble de règles (fichiers dans /etc/udev/rules.d/ et /lib/udev/rules.d/). Ces
règles permettent de :
1. Créer le nœud de périphérique correspondant dans /dev.

9
 2. Lui attribuer un nom persistant et explicite, indépendant de l’ordre de détection. Par exemple, un lien /dev/disk/by-uuid/ ou /dev/disk/by-
id/ pointant vers /dev/sdb. C’est ce qui permet de monter une partition par son UUID dans /etc/fstab de manière fiable.
3. Définir les permissions d’accès au périphérique (ex: donner l’accès en lecture/écriture au groupe plugdev pour les clés USB).
4. Déclencher des scripts (ex: exécuter mount automatiquement lors de l’insertion d’un disque externe).
Udev est la clé de l’expérience "plug-and-play" sous Linux moderne.
4.3. La pile logicielle des E/S

Lorsqu’une application écrite dans un fichier, la requête traverse une pile logicielle complexe qui isole les responsabilités et assure la modularité.
Ce parcours, de haut en bas, est le suivant :

1. Application : Appel de la fonction bibliothèque write().

2. Noyau – Appel système : Transition en mode noyau. L’appel système sys_write() est invoqué.
3. Noyau – VFS (Virtual File System) : Cette couche d’abstraction fournit une interface commune à tous les systèmes de fichiers. Elle route
l’appel vers les fonctions opérations spécifiques du système de fichiers sur lequel le fichier réside (par exemple, les
opérations ext4_file_operations).
4. Noyau – Système de fichiers (ex: ext4) : Le pilote ext4 traduit l’opération "écrire à la position X" en modifications de structures de données
précises : "mettre à jour l’extent Y, modifier l’inode Z". Il transmet ces demandes de modification de blocs à la couche de gestion des blocs.
5. Noyau – Gestion des blocs / Page Cache : Les données sont stockées dans le Page Cache. Les demandes de modifications sont placées
dans une file d’attente pour l’ordonnanceur d’E/S.
6. Noyau – Ordonnanceur d’E/S (ex: mq-deadline) : Réorganise les requêtes de blocs pour optimiser l’ordre d’exécution, puis les passe au
pilote du périphérique bloc.
7. Noyau – Pilote de périphérique bloc (ex: pilote NVMe) : Ce pilote spécifique au contrôleur matériel traduit les requêtes de blocs en
commandes compréhensibles par le contrôleur (commandes NVMe, par exemple).
10
 8. Matériel – Contrôleur et disque : Le contrôleur exécute les commandes sur le bus (PCIe) pour finalement lire ou écrire les secteurs sur
les puces NAND du SSD ou les plateaux du HDD.

Cette abstraction en couches est la force des systèmes d’exploitation modernes : on peut changer de système de fichiers, d’ordonnanceur ou de
disque dur sans jamais modifier le code de l’application ou des autres couches.

Ce cours a parcouru l’architecture interne des systèmes de fichiers, depuis les mécanismes fondamentaux assurant l’intégrité des données
jusqu’aux stratégies sophistiquées d’optimisation des performances. Le paysage des systèmes de fichiers est marqué par un compromis
permanent entre, d’une part, la simplicité, la vitesse et la stabilité (ext4) et, d’autre part, la richesse fonctionnelle, l’intégrité absolue et la
flexibilité de gestion (ZFS, Btrfs).
Les tendances actuelles sont profondément influencées par la montée en puissance des SSD et du NVMe, qui remettent en cause des décennies
d’algorithmes optimisés pour les disques mécaniques. Les systèmes de fichiers flash-aware comme F2FS (Flash-Friendly File System) sont
conçus spécifiquement pour les caractéristiques de la mémoire NAND (usure, effacement par blocs). Par ailleurs, l’émergence des mémoires
persistantes (PMEM) comme Intel Optane brouille la frontière traditionnelle entre mémoire et stockage, promettant des latences nanosecondes et
obligeant à repenser la pile logicielle des E/S.
Enfin, la virtualisation et le cloud poussent vers des systèmes de fichiers distribués (Ceph, GlusterFS) ou des systèmes optimisés pour la
conteneurisation (avec des couches de superposition efficaces comme dans OverlayFS). Comprendre les principes de base présentés ici est donc
essentiel pour aborder ces évolutions futures.

11