The File Forgets It Was Ever a Disk
The File Forgets It Was Ever a Disk
A filesystem's job is to make you stop thinking about the disk, and the layer that does the forgetting is the VFS — the virtual file system, the shim between "open this path" and the eleven different ways some driver actually keeps bytes.
Start with the inode. An inode is not a file's name — it is a file's identity, stripped of the name entirely: an inode number, a mode, an owner, a size, and a list of block pointers (direct blocks, then one indirect, then double-indirect, then triple, in the classic Unix layout — a scheme built to let a four-kilobyte structure address gigabytes without ever storing gigabytes of pointer). The name lives somewhere else, in a directory entry that pairs a string with an inode number. That separation is why a file can have two names (hard links, two directory entries, one inode, one refcount) and why deleting a name doesn't delete a file — it decrements a link count, and the inode survives, orphaned but real, until the count hits zero and the blocks are actually freed. rm never touches data directly; it edits a directory and maybe frees an inode. The unsettling case is an open file with its last link removed: the name is gone, ls shows nothing, but the process holding the descriptor keeps reading, because the kernel holds its own reference independent of any name — the file persists, invisible, until the last file descriptor closes.
Between the inode on disk and the process asking for a path sits the dentry — the directory entry cache, dcache. Every path lookup is a walk: split "/usr/glenda/lib" into components, resolve "usr" in the root directory to an inode, resolve "glenda" in that directory to another inode, and so on, one directory-block read per component if nothing is cached. The dcache exists purely to short-circuit that walk: it holds a tree of {name, parent, inode} triples so that the same path asked twice doesn't re-read directory blocks twice. It's a cache of the structure, not the content — it remembers what "usr" under root points to, not what's inside usr. Negative dentries are the sharp trick: the cache also remembers names that do not exist, so that a program repeatedly checking for a missing config file doesn't hit the disk every time to be told no. A dentry cache miss is one of the most common reasons a "warm" filesystem still feels slow the first time through a deep new directory tree — every level is a disk seek until the tree is in memory.
The page cache is the third layer, and it's the one that actually forgets the disk exists. File content is cached as pages — the same unit the memory manager already uses for RAM — so that a read() call is, on a warm cache, a memcpy out of a page that happens to be backed by a block device rather than swap. Write-back further defers the disk: a write() updates the page in memory and marks it dirty, returns immediately, and a writeback daemon flushes dirty pages to disk later, batched, in whatever order is efficient for the device rather than the order the program wrote them — which is why an unplugged machine after a write can lose data the program believes it already committed, and why fsync exists as the escape hatch: it blocks until this file's dirty pages are actually on stable storage, trading the whole point of the cache for a guarantee.
Memory-mapped files close the loop entirely: mmap asks the VFS to back a range of a process's address space directly with pages of a file, so that ordinary CPU load and store instructions — no read(), no write() — become the I/O mechanism, and a page fault on first touch is what actually pulls the block off disk. At that point the disk has become an implementation detail of memory itself, which is the whole quiet ambition of the VFS: three layers — identity (inode), structure (dentry), content (page) — stacked so a program calling open() never has to know if the bytes it gets back came from a spinning platter, a flash chip, or a network file server. Plan 9's own 9P protocol pushes this idea one step further than most: file operations themselves are the network protocol, so a remote resource and a local disk file are, from the calling program's point of view, indistinguishable walks through the same namespace.