Como funcionam os filesystems: inodes, journaling, e a page cache?

Question

IT Interview Practice · Accepted Answer

Um **filesystem** transforma um array plano de blocos de disco em uma hierarquia de arquivos e diretórios, gerenciando os metadados e o espaço livre para tornar isso confiável e rápido.

## Inodes: um arquivo é metadados + ponteiros de bloco

Nos filesystems UNIX, todo arquivo é um **inode** (index node) — uma estrutura que guarda os **metadados** do arquivo (tamanho, dono, permissões, timestamps, link count) e **ponteiros para seus blocos de dados**. Repare no que um inode *não* armazena: o **nome do arquivo**. Os nomes ficam nos **diretórios**, que são apenas arquivos que mapeiam nome → 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 isso que um **hard link** é apenas uma segunda entrada de diretório apontando para o mesmo inode (link count 2), e por que `rm` na verdade é `unlink` — ele remove um nome e libera o inode apenas quando o link count chega a zero.

## Journaling: sobrevivendo a crashes

Uma única operação lógica (ex. um append) toca vários blocos — o inode, o bitmap de espaço livre, os dados. Um crash no meio do caminho deixa o filesystem inconsistente. Um **journal** primeiro escreve as mudanças pretendidas em um log, depois as aplica; após um crash o FS refaz (replay) ou descarta o journal em vez de uma varredura completa e lenta (`fsck`). Os modos trocam segurança por velocidade: fazer journal **apenas dos metadados** (rápido, comum) versus dos metadados **e dos dados**.

## Page cache e caminhos de I/O

O kernel armazena os dados de arquivo na RAM na **page cache**, então as releituras acertam a memória e as escritas são **buffered** e descarregadas (flush) depois (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)
```

O I/O buffered é rápido, mas os dados "escritos" não são duráveis até o `fsync`; os bancos de dados frequentemente usam **direct I/O** mais seu próprio buffer pool para controlar caching e durabilidade com precisão.

## Por que isso importa

As entranhas do filesystem explicam comportamentos do dia a dia: por que hard links funcionam, por que apagar um arquivo que um processo ainda mantém aberto não libera espaço até ele fechar, por que o `fsync` é essencial para a durabilidade (e um bug clássico de perda de dados quando omitido), e por que a segunda leitura de um arquivo é instantânea (page cache). Engenheiros senior raciocinam sobre isso ao escolher I/O buffered vs direct para um banco de dados, dimensionar a RAM para cache, ou depurar um problema de consistência após crash.

Inodes: um arquivo é metadados + ponteiros de bloco

Journaling: sobrevivendo a crashes

Page cache e caminhos de I/O

Por que isso importa

Perguntas relacionadas