¿Cómo funcionan los filesystems: inodes, journaling y la page cache?

Question

IT Interview Practice · Accepted Answer

Un **filesystem** convierte un array plano de bloques de disco en una jerarquía de archivos y directorios, gestionando los metadatos y el espacio libre para hacerlo fiable y rápido.

## Inodes: un archivo es metadatos + punteros a bloques

En los filesystems UNIX, cada archivo es un **inode** (index node) — una estructura que contiene los **metadatos** del archivo (tamaño, propietario, permisos, timestamps, link count) y **punteros a sus bloques de datos**. Fíjate en lo que un inode *no* almacena: el **nombre del archivo**. Los nombres viven en los **directorios**, que son solo archivos que mapean nombre → número de 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)──▶ ...
                                 └──────────────┘
```

Por eso un **hard link** es solo una segunda entrada de directorio que apunta al mismo inode (link count 2), y por eso `rm` es en realidad `unlink` — elimina un nombre y libera el inode solo cuando el link count llega a cero.

## Journaling: sobrevivir a los crashes

Una sola operación lógica (p. ej. un append) toca varios bloques — el inode, el bitmap de espacio libre, los datos. Un crash a mitad de camino deja el filesystem inconsistente. Un **journal** primero escribe los cambios previstos en un log, y luego los aplica; tras un crash el FS reproduce (replay) o descarta el journal en lugar de un escaneo completo lento (`fsck`). Los modos intercambian seguridad por velocidad: journal **solo de metadatos** (rápido, común) frente a metadatos **y datos**.

## Page cache y rutas de I/O

El kernel cachea los datos de archivo en RAM en la **page cache**, de modo que las relecturas van a memoria y las escrituras se **bufferean** y se vuelcan (flush) más tarde (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)
```

La buffered I/O es rápida, pero los datos "escritos" no son durables hasta `fsync`; las bases de datos a menudo usan **direct I/O** más su propio buffer pool para controlar el caching y la durabilidad con precisión.

## Por qué es importante

Los entresijos del filesystem explican el comportamiento cotidiano: por qué funcionan los hard links, por qué borrar un archivo que un proceso aún tiene abierto no libera espacio hasta que lo cierra, por qué `fsync` es esencial para la durabilidad (y un bug clásico de pérdida de datos cuando se omite), y por qué la segunda lectura de un archivo es instantánea (page cache). Los ingenieros senior razonan sobre esto al elegir buffered vs direct I/O para una base de datos, dimensionar la RAM para la cache, o depurar un problema de consistencia tras un crash.

Inodes: un archivo es metadatos + punteros a bloques

Journaling: sobrevivir a los crashes

Page cache y rutas de I/O

Por qué es importante

Preguntas relacionadas