Disks, partitions, and volumes

Storage & file systems named disk, partition, and volume as the first three layers of the storage stack. This chapter unpacks exactly what distinguishes them, since the three terms get used loosely in everyday conversation but mean specific, different things internally.

Three layers, three distinct concepts

• A disk is raw storage capacity — a physical drive, or a virtual one presented by a hypervisor or storage virtualization layer. On its own, a disk is just addressable blocks; nothing about it says how that capacity is organized.
• A partition is a defined region of a disk — a range of blocks set aside, described by a partitioning scheme (GPT or the older MBR) recorded near the start of the disk. A disk can hold several partitions, each independently sized and typed.
• A volume is the logical storage surface Windows actually chooses to expose for I/O — built from one partition, in the common case, but not necessarily always a one-to-one mapping (some configurations, like certain RAID or dynamic-disk setups, build a single volume spanning multiple partitions or even multiple physical disks).

The practical takeaway: a partition existing doesn't automatically mean a usable, mounted volume exists — and a volume being present doesn't tell you, by itself, how many partitions or physical disks are actually behind it.

Why one disk can show multiple drive letters

Because volumes, not disks, are what get namespace-exposed to users and applications, a single physical disk with multiple partitions can present as several entirely separate drive letters — each one a distinct volume, each with its own file system, its own free space accounting, its own security settings, even though all of them ultimately share the same underlying physical hardware and its performance characteristics. This is exactly why "how much free space does this disk have" is a genuinely different, and sometimes unanswerable-as-asked, question from "how much free space does this volume have" — the disk's total capacity is split across partitions that may not even all be visible as mounted volumes.

Volume GUID paths: identity independent of assignment

Every volume Windows recognizes gets a stable volume GUID path (something like \\?\Volume{...}\), assigned once and persisting regardless of whether — or which — drive letter is currently assigned to it. This is the mechanism that lets Windows correctly recognize "this is the same USB drive I saw yesterday, even though it happened to get a different letter this time" — the GUID path is the volume's actual, durable identity; the drive letter is just a convenience mapping on top of it, reassignable and not guaranteed stable across removals and reconnections.

A worked example: a removable drive that "changes" letters

Plugging the same USB drive into a machine on two different occasions, and getting E: the first time and F: the second (because something else already occupied E:), is a completely ordinary, expected outcome given this model — the volume's actual identity (its GUID path, its file-system contents, its formatting) hasn't changed at all; only the namespace convenience layered on top has. Software that needs to reliably re-identify "the same volume" across sessions generally keys off the GUID path or a file-system-level identifier, precisely because drive letters were never designed to be a stable identity.

A common mistake

Assuming a partition and a volume are interchangeable — or that a disk maps to exactly one volume — glosses over configurations (multi-partition disks, spanned or RAID volumes) that are common in real deployments, particularly on servers. Reasoning precisely about storage, especially when troubleshooting free-space or performance questions, requires keeping "disk," "partition," and "volume" as three separate, independently-checkable facts rather than assuming any one implies the others.

Where this connects

• File systems covers what actually gets written onto a volume once one exists — the interpretation layer that turns raw volume space into directories and files.
• Drivers & device stacks covers the disk and volume-manager drivers that actually implement the layering described here.