How do filesystems work: inodes, journaling, and the page cache?

Question

IT Interview Practice · Accepted Answer

A **filesystem** turns a flat array of disk blocks into a hierarchy of files and directories, managing the metadata and free space to make that reliable and fast.

## Inodes: a file is metadata + block pointers

In UNIX filesystems, every file is an **inode** (index node) — a structure holding the file's **metadata** (size, owner, permissions, timestamps, link count) and **pointers to its data blocks**. Note what an inode does *not* store: the **filename**. Names live in **directories**, which are just files mapping name → inode number:

```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)──▶ ...
                                 └──────────────┘
```

This is why a **hard link** is just a second directory entry pointing at the same inode (link count 2), and why `rm` is really `unlink` — it removes a name and frees the inode only when the link count hits zero.

## Journaling: surviving crashes

A single logical operation (e.g. an append) touches several blocks — the inode, the free-space bitmap, the data. A crash mid-way leaves the filesystem inconsistent. A **journal** first writes the intended changes to a log, then applies them; after a crash the FS replays (or discards) the journal instead of a slow full scan (`fsck`). Modes trade safety for speed: journal **metadata only** (fast, common) versus metadata **and data**.

## Page cache & I/O paths

The kernel caches file data in RAM in the **page cache**, so re-reads hit memory and writes are **buffered** and flushed later (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)
```

Buffered I/O is fast, but "written" data isn't durable until `fsync`; databases often use **direct I/O** plus their own buffer pool to control caching and durability precisely.

## Why it matters

Filesystem internals explain everyday behavior: why hard links work, why deleting a file that a process still holds open doesn't free space until it closes, why `fsync` is essential for durability (and a classic data-loss bug when omitted), and why the second read of a file is instant (page cache). Senior engineers reason about these when choosing buffered vs direct I/O for a database, sizing RAM for cache, or debugging a crash-consistency issue.

Inodes: a file is metadata + block pointers

Journaling: surviving crashes

Page cache & I/O paths

Why it matters

Related questions