← Operating System Concepts

BOOK NOTES · OPERATING SYSTEMS · CHAPTER 15

Operating System Concepts Chapter 15 — File-System Internals.

operating-systemschapter-15vfsinodejournalingnfs

// the one-minute version

Real systems run many file systems at once — ext4, NTFS, a USB's FAT, a network share — yet you use them all the same way. The trick is the virtual file system (VFS), an abstraction layer giving every file system one common interface. This chapter also covers remote file systems (NFS), consistency semantics, and the crash-safety mechanism that replaced slow whole-disk repair: journaling.

Open a file on your SSD, a USB stick, and a network drive with the exact same open call — though all three store data completely differently. That seamlessness isn't luck; it's a deliberate abstraction layer inside the kernel.

01 The virtual file system (VFS)

The VFS sits between system calls and the actual file systems. It defines a standard interface — open, read, write, and abstract objects like the file, the inode, and the directory entry (dentry) — that every concrete file system implements its own way. The kernel and applications talk only to the VFS; the VFS routes each call to the right file system's code.

key ideaVFS is the same design idea as device drivers (Chapter 12): a uniform interface on top, pluggable implementations below. Add support for a new file-system format by writing a module that fits the VFS interface — nothing above it changes. This is why one OS can mount dozens of file-system types simultaneously.
think of it likeVFS is a universal power adapter. Your laptop (the kernel) has one plug shape. Behind the adapter, the wall socket might be US, EU, or UK (ext4, NTFS, FAT). The adapter translates so the laptop never needs to know which country it's in.

02 Inodes and the in-memory caches

Each open file is represented in memory by VFS structures backed by the file system's on-disk inode. The kernel caches active inodes and directory lookups in RAM (the inode cache and dentry cache) so repeated access to the same files and paths doesn't keep hitting the disk — path resolution like /home/user/file would otherwise be many disk reads.

03 Mounting, revisited

Mounting is what lets multiple file systems form one tree. When you mount a volume at /mnt/usb, the VFS records that crossing that path switches to the USB's file system. Walk into that directory and the VFS transparently hands operations to the FAT driver instead of ext4 — you never notice the boundary. The mount table tracks all these crossings.

04 Remote file systems

A file system can live on another machine. The Network File System (NFS) and similar protocols let a client mount a server's directory and use it like a local one — the VFS routes operations across the network instead of to a local disk. NFS was deliberately designed to be stateless on the server side (each request is self-contained) so a server crash-and-reboot doesn't lose client sessions.

watch outRemote file systems inherit all of distributed computing's hard problems. The network can be slow or drop; the server can crash mid-operation; two clients can cache the same file and disagree. "It's just a folder" hides genuine consistency and failure challenges that local file systems never face — which is why the next topic, consistency semantics, exists.

05 Consistency semantics

When multiple processes (or clients) share a file, consistency semantics define when one's writes become visible to another. UNIX semantics make a write visible immediately to everyone with the file open — intuitive but hard over a network. Session semantics (used by some network file systems) only make changes visible after the writer closes the file. Knowing which model applies is essential for reasoning about shared-file behavior.

06 Consistency and journaling

Chapter 14 ended on crash-consistency: a power loss mid-update leaves structures contradicting each other, and the old fsck repair scans the whole disk — unbearably slow on large volumes. Journaling fixes this elegantly. A journaling file system first writes its intended changes to a journal (a log) before applying them to the main structures. After a crash, the OS just replays the journal — finishing committed changes, discarding incomplete ones. Recovery takes seconds, not a full-disk scan. ext4, NTFS, and XFS all journal.

noteJournaling is the same write-ahead-log idea databases use. The insight: make the record of intent durable before the actual change, so you can always either roll forward (finish it) or roll back (discard it) after a crash. No inconsistent in-between state to puzzle over. Many file systems journal only metadata (fast, protects structure) rather than full data (safer, slower) — a deliberate trade-off.

07 Performance: caching everywhere

File systems lean hard on RAM caching: a page cache/buffer cache keeps recently read disk blocks in memory, so hot files are served without touching storage. Writes are often buffered and flushed later (write-back), which is fast but means a crash can lose very recent writes — the eternal speed-vs-safety trade-off, and the reason for fsync and safe-eject.

common catches & gotchas

  • VFS is an interface, not a file system — It stores nothing on disk itself — it routes to real file systems. Confusing it with a concrete FS is a common slip.
  • Metadata vs data journaling — Most file systems journal only metadata by default. Your file structure survives a crash, but recent file contents may not. Don't assume full durability.
  • Network FS ≠ local FS — NFS looks like a folder but faces delays, drops, and server crashes. Treating it as a fast local disk leads to surprises and hangs.
  • Write-back can lose data — Buffered writes sit in RAM before hitting disk. A crash before flush loses them — which is why fsync and proper unmount matter.
  • Consistency semantics vary — Whether your write is instantly visible to others depends on the model (UNIX vs session). Shared-file bugs often trace to wrong assumptions here.

08 Questions students actually ask

What does the VFS do?

It provides one common interface for all file systems, so applications and the rest of the kernel use any file system — local, USB, or network — through identical calls. Each concrete file system plugs in beneath it.

How can one computer use ext4, NTFS, and FAT at once?

Each is a module implementing the VFS interface. The VFS routes each operation to the right module based on where the file lives (which mount it's under), so they coexist transparently under one tree.

How does journaling speed up crash recovery?

It writes intended changes to a log before applying them. After a crash, the OS replays the log — finishing committed changes, discarding incomplete ones — in seconds, instead of scanning the whole disk like fsck.

Why are network file systems harder than local ones?

They face network delays and failures, server crashes mid-operation, and cache-consistency problems when multiple clients access the same files. A local file system never reasons about an unreliable network in between.

Does journaling protect my file contents?

Often only partially. Many file systems journal metadata (structure) by default, not full data, for speed. Your file system stays consistent after a crash, but very recent file contents may still be lost.

09 Key takeaways

  • The VFS gives every file system one common interface — uniform on top, pluggable below.
  • It's the same pattern as drivers: add a file-system type by writing a module that fits the interface.
  • Inode and dentry caches keep hot metadata in RAM.
  • Remote file systems (NFS) mount another machine's storage — with distributed-systems hazards.
  • Consistency semantics define when one process's writes become visible to others.
  • Journaling logs intended changes first, making crash recovery fast — often metadata-only.

10 Wrapping up

That completes the storage and file-system arc. The remaining chapters turn to keeping all of this safe and isolated — starting with the threats and defenses of security. Next up: Security.

← prev: Chapter 14next: Chapter 16 →
© cvam — written in plaintext, served warm