Linux Filesystem Kernel Subsystem — Architecture & Write Path

The Write Path Through the Linux Filesystem Architecture

This page visualizes the Linux filesystem architecture as a live write path from userspace to persistent storage. When an application calls write(), the Virtual File System (VFS) dispatches the operation to a concrete filesystem such as ext4. Data first lands in the page cache as dirty pages; the kernel later flushes those pages via writeback, throttling writers with balance_dirty_pages when dirty memory approaches the configured ratios. Flushed blocks pass through the block layer and an I/O scheduler, are journaled by jbd2 for crash consistency, and are finally written to the device. The visualization is driven by real kernel counters from /proc and /sys.

Filesystem Layers

• VFS — the virtual filesystem: inodes, dentries, the file and superblock objects, and the common syscall interface (open, read, write, stat).
• Page cache — cached file pages, dirty-page accounting and read-ahead.
• Writeback — dirty-page flushing, dirty_ratio/dirty_background_ratio thresholds and balance_dirty_pages throttling.
• Block / IO scheduler — the bio/request layer, merging and the active I/O scheduler (mq-deadline, BFQ, none).
• ext4 — inodes, extent trees mapping logical file blocks to physical device blocks, and block groups.
• jbd2 journaling — the transaction lifecycle (running, committing, checkpoint) that guarantees crash consistency and durability.
• dentry cache — path resolution component-by-component, with cached and negative dentries kept on an LRU.

Kernel Architecture Context

The filesystem is one of the core Linux kernel subsystems, sitting between the process and memory subsystems above and the block device drivers below. Understanding the filesystem architecture — VFS abstraction, page cache, writeback and journaling — is central to reasoning about the overall Linux architecture and kernel architecture: how data durability, I/O latency and memory pressure interact.