Filesystem Fundamentals

Inodes, journaling, VFS, and how files are actually stored

What a Filesystem Actually Is

A filesystem is a data structure laid out on top of a block device. The block device exposes a flat array of fixed-size sectors (typically 512 B or 4 KiB); the filesystem adds meaning on top of that — a mapping from human-readable names to ranges of blocks, plus metadata describing ownership, timestamps, permissions, and integrity.

1. Path

   /var/log/syslog

2. Dentry

   name → inode #

3. Inode

   metadata + block ptrs

4. Data blocks

   actual bytes on disk

The Core On-Disk Structures

Superblock

A single structure (with backup copies) describing the filesystem as a whole. Located at a well-known offset so the kernel can find it during mount().

• Magic number — identifies the filesystem type (e.g. 0xEF53 for ext2/3/4). Without it, the kernel doesn't know which driver to invoke.
• Total size, block size, block count — geometry of the filesystem.
• Free block / free inode counters — quick stats.
• Mount count, last mount time, last fsck time, state flag — used to decide when to force an fsck.
• UUID and label — stable identifiers independent of device path.

Inode (Index Node)

One inode per file. It holds everything about the file except its name. Names live in directory entries, not in the inode itself — this is why hard links are cheap (multiple dentries pointing to the same inode).

Crucially, the filename is not in the inode. An inode doesn't know what it's called. If you ls -li, the leftmost column is the inode number — and two directory entries can point at the same inode (hard link).

Directory Entry (dentry)

A directory is just a special file whose "contents" are a list of (name, inode number) pairs. The Linux kernel also caches these in memory as the dentry cache to accelerate path lookups — walking /a/b/c/d would otherwise require four disk reads per lookup.

Block Groups / Allocation Groups

Rather than keeping all metadata in one corner of the disk (disastrous if that region fails, and terrible for locality), modern filesystems split the device into independent regions:

Inodes in Depth

Extent Trees vs Indirect Block Pointers

How does an inode point to a potentially huge file's data?

# 1 TB file = millions of pointer entries
# each indirect lookup = extra read

# 1 TB file, unfragmented:
# ~8 extent records total

Inode Exhaustion

On ext filesystems, inodes are pre-allocated at mkfs time. The default is roughly one inode per 16 KiB of filesystem capacity. On a workload full of tiny files (Maildir, node_modules, container image layers), you can run out of inodes while still having free blocks.

$ df -i /var
Filesystem       Inodes  IUsed    IFree IUse% Mounted on
/dev/sda1      6553600 6553600       0  100% /var
$ # ENOSPC despite "df" showing free space
  

Data Blocks, Allocation & Fragmentation

When a write extends a file, the allocator must pick new blocks. Strategies:

• Block bitmaps (ext) — a bit per block, scanned linearly with locality hints.
• Free-space B+trees (XFS, btrfs) — scale to petabytes; O(log n) lookups.
• Delayed allocation (ext4, XFS) — don't pick blocks until fsync or writeback; lets the allocator see the full write size and place it contiguously.

Fragmentation is when a file's blocks are scattered rather than contiguous. On spinning rust, this hurts sequential read throughput badly. On flash it matters far less — SSDs have no seek penalty — but extent maps still grow and consume cache.

Journaling: Crash Consistency

A write typically touches multiple structures: inode, block bitmap, data blocks, directory entry. If the machine crashes mid-write, the filesystem can end up inconsistent — e.g. a block marked allocated in the bitmap but not referenced by any inode.

A journal (also called a log) solves this by writing intended changes to a dedicated region first, then applying them to the main filesystem. On crash recovery, unfinished transactions are either replayed or discarded.

1. Begin transaction

2. Write changes to journal

3. Commit record (barrier)

4. Checkpoint to main FS

5. Free journal space

ext4 Journal Modes

VFS — The Virtual Filesystem

Linux supports dozens of filesystem types. User-space code doesn't care: open(), read(), write(), stat() all behave the same whether the backing store is ext4, XFS, NFS, FUSE, tmpfs, or procfs. This is the VFS layer — a kernel abstraction that presents a uniform object-oriented interface over every concrete filesystem.

Each concrete filesystem registers a struct file_operations (and inode/super/address-space op tables). When you call read(fd, …), the kernel resolves fd to a struct file, finds its f_op->read_iter, and dispatches into the filesystem driver. It's vtables, all the way down.

Mounting

Mounting attaches a filesystem to a point in the VFS namespace. The mount(2) syscall takes a source (device or spec string), a target directory, a filesystem type, flags, and type-specific options.

# mount -t ext4 -o noatime,discard /dev/sda1 /mnt/data
# mount -t xfs   -o noatime,logbsize=256k /dev/sdb1 /srv
# mount -t tmpfs -o size=2G tmpfs /run/cache
  

Bind Mounts

A bind mount exposes an existing directory subtree at another location, without copying. Essential for chroot/container setups.

# mount --bind  /var/log  /mnt/chroot/var/log   # flat bind
# mount --rbind /dev      /mnt/chroot/dev        # recursive: includes /dev/pts, /dev/shm...
  

Mount Propagation Types

Mounts live inside mount namespaces. When a namespace is cloned, each mount carries a propagation flag controlling whether subsequent mount/umount events cross the namespace boundary.

/etc/fstab

The mount manifest, read at boot by systemd (via systemd-fstab-generator). Six whitespace-separated fields per line:

# <source>                               <mountpoint>  <type>  <options>                       <dump> <pass>
UUID=3f9a1b6e-...-01                   /             ext4    defaults,errors=remount-ro      0      1
UUID=6eba52a0-...-02                   /home         xfs     defaults,noatime                0      2
LABEL=swap                             none          swap    sw                              0      0
/dev/vg_data/lv_backup                 /backup       xfs     noauto,x-systemd.automount      0      0
tmpfs                                  /tmp          tmpfs   size=4G,noexec,nosuid,nodev     0      0
192.0.2.10:/export/share               /mnt/nfs      nfs     rw,_netdev,nofail,x-systemd.after=network-online.target  0 0
  

Source Identifier — Pick Wisely

Important Option Flags

• nofail — don't block boot if the source is missing. Essential for non-critical mounts.
• noauto — don't mount at boot; mount explicitly later.
• x-systemd.automount — lazy-mount on first access (fuse-style behavior via systemd).
• x-systemd.after=, _netdev — ordering hints, especially for networked filesystems.
• noatime, relatime, strictatime — control atime updates. Most modern distros use relatime by default.
• dump field — historical, used by the dump(8) backup tool. Almost always 0.
• pass field — fsck order at boot. 1 for root, 2 for other disks, 0 to skip.

Durability: fsync, fdatasync, O_DIRECT, Barriers

A successful write(2) means the kernel accepted your bytes into the page cache — not that they hit stable storage. Between you and the platter sit: page cache, filesystem journal, block layer queues, device write caches. Databases and message brokers care intensely about the details.

fsck: The Filesystem Checker

fsck walks the filesystem structures, detects inconsistencies, and repairs them. It's both a safety net and a footgun.

• Runs at boot via the pass column of fstab.
• Triggered every N mounts or T days on ext filesystems — tune with tune2fs -c <count> -i <interval>.
• Force a check: fsck -f /dev/sdaX.
• For XFS, the userspace tool is xfs_repair, and XFS also does metadata-only log replay at mount.

Pseudo-Filesystems

Not every filesystem is backed by a block device. Several kernel filesystems exist purely to present kernel state or RAM through the familiar file API.

Takeaways

• Filesystems impose structure on a flat block device: superblock → block groups → inodes → dentries → data.
• An inode is metadata + pointers; the filename is stored in the parent directory's dentry list.
• Extents replaced indirect blocks — big win for large contiguous files.
• ext pre-allocates inodes; XFS allocates them dynamically. Plan accordingly on small-file workloads.
• Journaling protects filesystem structure. For application durability, use fsync/fdatasync.
• VFS is the kernel abstraction that makes ext4, NFS, and procfs look identical to user space.
• Mount namespaces + propagation types are what make container runtimes possible.
• Prefer UUID= in fstab. Add nofail to optional mounts.
• Never run fsck on a mounted filesystem.