Section 1: The Storage Stack

The Big Picture: A Package Going Down a Chain of Offices

When you double-click a photo, your request does not jump straight to the SSD. It passes through a chain of helpers, a bit like a parcel passing through offices in a building. Each office does one small job and hands the parcel to the next floor down.

Why so many layers? Because each layer can be swapped without touching the others. You can change an SSD from SATA to NVMe, or format a volume with a different file system, and your photo app does not need to know. This chain is called the storage stack.

This section gives you the whole map. The rest of the chapter zooms into each layer. Here is the stack for a typical Windows 10 or 11 PC, top to bottom:

┌──────────────────────────────────────────────┐
│ Application (Explorer, Word, a game)         │  user mode
├──────────────────────────────────────────────┤
│ Win32 file API (CreateFile, ReadFile)        │  user mode
╞══════════════════════════════════════════════╡
│ I/O Manager (builds the request, an IRP)     │  kernel mode
├──────────────────────────────────────────────┤
│ File system driver (ntfs.sys, refs.sys ...)  │  kernel mode
├──────────────────────────────────────────────┤
│ Volume manager (volmgr.sys + filter drivers) │  kernel mode
├──────────────────────────────────────────────┤
│ Partition manager (partmgr.sys)              │  kernel mode
├──────────────────────────────────────────────┤
│ Disk class driver (disk.sys)                 │  kernel mode
├──────────────────────────────────────────────┤
│ Storage port driver (storport.sys)           │  kernel mode
├──────────────────────────────────────────────┤
│ Miniport (stornvme.sys, storahci.sys)        │  kernel mode
╞══════════════════════════════════════════════╡
│ Hardware: NVMe / AHCI controller, then disk  │  hardware
└──────────────────────────────────────────────┘

(User mode and kernel mode were explained earlier in the course: user mode is where ordinary programs run with limited rights; kernel mode is where the core of Windows and its drivers run with full rights.)

1.1 The Top: Application, Win32 API and I/O Manager

What it is: The top three layers turn "open this file" into an internal request that the kernel can pass down.

1. The application is any program that wants a file: Explorer, Word, a game, even Windows Update.
2. The Win32 file API is the set of ready-made functions that Windows offers programs. The most famous are:

3. The I/O Manager is the part of the kernel that receives the call. It builds a small packet called an IRP (I/O Request Packet). An IRP is a form that says "read 4,096 bytes from this file starting at this spot." (IRPs and drivers are covered in Chapter 13.)

The I/O Manager then passes the IRP to the first driver in the chain. Each driver either finishes the job or changes the form slightly and passes it down.

1.2 The File System Driver

What it is: The file system driver understands files and folders. It knows that "Holiday.jpg" is stored in certain chunks on disk, and it keeps the folder structure, names, permissions and times.

Common file system drivers on Windows:

(Exact driver file names vary a little between Windows versions. Later chapters cover the file systems themselves.)

Here is the key idea. The file system thinks in files, but the layers below think in blocks. So it translates: "bytes 0–4095 of Holiday.jpg" becomes "volume blocks 81,920 to 81,927." After that, the request is about the volume, not about files at all.

1.3 The Volume and Partition Layers

What it is: Below the file system, Windows has to turn "position on a volume" into "position on a disk". Two layers do this.

• Volume manager (volmgr.sys). It creates the volume object that the file system sits on. (A volume is a chunk of storage with one file system; Section 2 defines it properly.) Several filter drivers can sit around this layer. A filter driver is a helper that watches or changes requests passing by. Two examples (the exact order differs between systems, so treat the picture as a guide):
  • volsnap.sys makes shadow copies (point-in-time snapshots used by "Previous Versions" and System Restore).
  • fvevol.sys handles BitLocker (it encrypts data on its way down and decrypts it on its way up).
• Partition manager (partmgr.sys). It reads the disk's partition table (Section 3) and knows where each partition starts. It adds that start position to the request, so "block 0 of the volume" becomes "block 1,050,624 of the disk."

File system says:   "volume block 8"
Partition manager:  partition starts at disk block 1,000  ──►  "disk block 1,008"

1.4 Disk Class, Port and Miniport Drivers

What it is: The bottom drivers talk to the real hardware. Windows splits this into three layers so that each one stays small and reusable.

Think of it like a delivery company: disk.sys writes the address label, storport.sys runs the sorting depot, and the miniport is the driver who knows the one road to your street. Section 6 goes deeper.

1.5 Following One Read Request All the Way

Let's trace a real read. You open a text file and the program calls ReadFile.

1. App          ReadFile(handle, buffer, 4096 bytes)
2. I/O Manager  Builds an IRP, sends it to the file system
3. NTFS         Looks up where those bytes live: "volume block 8,000"
4. Volume and   Adds the partition start: "disk block 1,008,000"
   partition
5. disk.sys     Builds a standard "read blocks" command
6. storport     Puts the command in a queue, sets a timer
7. stornvme     Writes the command into the SSD's queue, rings its doorbell
8. SSD          Finds the data, copies it into RAM using DMA,
                raises an interrupt
9. Back up      The completion travels up the same chain; the IRP completes;
                ReadFile returns; your program sees the bytes

Two links to earlier chapters:

• Step 8 uses DMA and interrupts from Chapter 4. The SSD writes straight into RAM and then taps the CPU on the shoulder when done.
• The devices at the bottom (NVMe SSDs, SATA drives) are described in Chapter 18.

Tip: Often the data is not read from the disk at all. Windows keeps recently used file data in RAM (the file cache), and the file system answers from there. The stack below the file system is only used on a cache miss (the data was not in the cache).

1.6 Why Layering Helps You as a User

Summary