Storage & file systems

The I/O system described requests flowing through a device stack in general terms. Storage is the single most elaborate, most heavily used example of exactly that pattern — and it's worth its own overview before going into its individual pieces.

The layers, in order

Storage on Windows is genuinely layered, and each layer answers a distinct question:

1. Hardware or virtual disk — the raw block device, physical or virtualized.
2. Partition and volume — carving and describing logical regions of that raw capacity. Disks, partitions, and volumes covers this.
3. File system — interpreting the bytes within a volume as directories, files, and metadata. File systems covers this.
4. Cache — keeping recently-used file data resident in memory to avoid re-reading it from disk unnecessarily. The Cache Manager covers this.
5. Namespace — the drive letters, volume GUID paths, and (via reparse points) redirections that present all of the above to applications as recognizable paths. Reparse points & symlinks covers a key piece of this.

Why "a drive letter" is a thin, replaceable view

A drive letter is genuinely just one namespace convenience layered on top of everything else — it's not the volume itself, and it's not even a required way of addressing a volume. Windows also exposes every volume through a stable volume GUID path, independent of whatever drive letter (if any) happens to be assigned. This is precisely why a USB drive can be unplugged and reconnected, potentially getting a different letter, while still being identifiably "the same volume" underneath — the letter is an assignment, not an identity.

A worked example: opening a document

Opening a file by a path like C:\Users\you\Documents\report.docx looks like a single, flat lookup. It actually resolves through every layer above: C: maps to a specific volume (namespace layer), that volume is backed by a partition on some physical or virtual disk (volume layer), the path components are resolved against the file system's own directory and metadata structures (file-system layer, likely consulting NTFS's Master File Table), and — if any part of that path has recently been accessed — much of this may be satisfied from cached pages rather than a fresh disk read (cache layer). None of this layering is visible to the calling application; it's exactly the kind of invisible-when-working infrastructure this whole course keeps returning to.

A common mistake

Treating "a drive letter" as synonymous with "a disk" collapses several genuinely distinct concepts into one, and it's the single most common source of confusion when reasoning carefully about storage: a physical disk can host multiple partitions, each carved into one or more volumes, each of which can be presented through multiple namespace paths (a drive letter, a mount point inside another volume, a raw GUID path) simultaneously. "The C: drive" is really shorthand for one specific namespace assignment pointing at one specific volume — useful shorthand, but not literally accurate to what's actually there.

Where this connects

• The I/O Manager and Drivers & device stacks cover the general request-routing machinery every layer above rides on.
• Memory management is deeply intertwined with the cache layer — cached file data is, underneath, ordinary memory-managed pages.