Comment fonctionnent les systèmes de fichiers : inodes, journaling et page cache ?

Question

IT Interview Practice · Accepted Answer

Un **système de fichiers (filesystem)** transforme un tableau plat de blocs disque en une hiérarchie de fichiers et de répertoires, en gérant les métadonnées et l'espace libre pour rendre cela fiable et rapide.

## Inodes : un fichier, c'est des métadonnées + des pointeurs de blocs

Dans les filesystems UNIX, chaque fichier est un **inode** (index node) — une structure contenant les **métadonnées** du fichier (taille, propriétaire, permissions, horodatages, link count) et des **pointeurs vers ses blocs de données**. Notez ce qu'un inode ne stocke *pas* : le **nom de fichier**. Les noms résident dans les **répertoires (directories)**, qui ne sont que des fichiers associant nom → numéro d'inode :

```text
directory "docs"                  inode 1042              data blocks
┌───────────────────┐            ┌──────────────┐         ┌────────┐
│ "report.txt" →1042│───────────▶│ mode, uid    │──ptr───▶│ block  │
│ "notes.txt"  →1050│            │ size, times  │──ptr───▶│ block  │
└───────────────────┘            │ link count=2 │         └────────┘
                                 │ block ptrs   │──(indirect)──▶ ...
                                 └──────────────┘
```

C'est pourquoi un **hard link** n'est qu'une seconde entrée de répertoire pointant vers le même inode (link count 2), et pourquoi `rm` est en réalité `unlink` — il supprime un nom et ne libère l'inode que lorsque le link count atteint zéro.

## Journaling : survivre aux crashs

Une seule opération logique (p. ex. un append) touche plusieurs blocs — l'inode, le bitmap d'espace libre, les données. Un crash à mi-parcours laisse le filesystem incohérent. Un **journal** écrit d'abord les changements prévus dans un log, puis les applique ; après un crash, le FS rejoue (replay) ou abandonne (discard) le journal au lieu d'un lent scan complet (`fsck`). Les modes échangent la sécurité contre la vitesse : journaliser **les métadonnées uniquement** (rapide, courant) versus les métadonnées **et les données**.

## Page cache & chemins d'I/O

Le kernel met en cache les données de fichiers en RAM dans le **page cache**, de sorte que les relectures atteignent la mémoire et que les écritures sont **bufferisées** puis flushées plus tard (write-back) :

```text
buffered I/O (default): app ↔ page cache ↔ disk   → cached, async writeback, fast re-reads
direct I/O (O_DIRECT):  app ↔ disk                → bypass the cache; DBs manage their own
fsync():                force buffered data to durable storage (required for real durability)
```

L'I/O bufferisé est rapide, mais les données « écrites » ne sont pas durables tant qu'il n'y a pas de `fsync` ; les bases de données utilisent souvent le **direct I/O** plus leur propre buffer pool pour contrôler précisément le cache et la durabilité.

## Pourquoi c'est important

Les rouages internes du filesystem expliquent des comportements quotidiens : pourquoi les hard links fonctionnent, pourquoi supprimer un fichier qu'un processus garde encore ouvert ne libère pas l'espace tant qu'il ne le ferme pas, pourquoi `fsync` est essentiel à la durabilité (et un bug de perte de données classique quand il est omis), et pourquoi la seconde lecture d'un fichier est instantanée (page cache). Les ingénieurs seniors raisonnent là-dessus lorsqu'ils choisissent buffered vs direct I/O pour une base de données, dimensionnent la RAM pour le cache, ou déboguent un problème de cohérence après crash.

Inodes : un fichier, c'est des métadonnées + des pointeurs de blocs

Journaling : survivre aux crashs

Page cache & chemins d'I/O

Pourquoi c'est important

Questions connexes