Disk: Explanation & Insights

The thing that remembers. Everything else in the box forgets when the power dies.

What It Is

A disk is the device that holds your data when the lights go out. RAM forgets the instant the power drops; the disk remembers. That single property — persistence — is the whole reason it exists, and it shapes everything about how the machine treats it. The CPU is fast and forgetful. The disk is slow and faithful. A server is, at heart, the negotiation between those two facts, and most of what you'll ever tune, watch, or curse comes down to managing the gap between them.

The word "disk" is a fossil. It comes from a literal spinning platter — a coated metal circle, whirling thousands of times a minute under a magnetic head that floats nanometres above the surface, writing and reading bits as patches of magnetism. That machine still exists and still sells by the exabyte, but the word has long outgrown the object. A modern solid-state drive has no disk in it at all — no platter, no spin, no moving part anywhere — yet we still call it a disk, mount it like a disk, and df it like a disk. The name survived the technology it named. Unix is full of these: we still say "dial a number," and Linux still calls a storage device a disk even when it's a chip the size of a stamp.

This page is the orientation map for storage on a Linux server. It ties together the concepts that branch off it — how the kernel sees a disk as a block device, the three hardware families and how far apart they really are in speed, what sits on a disk (partitions and filesystems), how a disk works when there is no physical disk at all (cloud and virtual machines), and how to think about capacity versus performance without hand-waving. By the end you'll know what /dev/sda actually is, why /dev/nvme0n1 is named so strangely, and why "the disk is the bottleneck" is the single most common — and most often wrong — diagnosis a new admin reaches for.

Why It Matters

Storage is where servers go to die quietly. A CPU that's pinned at 100% screams at you in every monitoring tool you own. A disk that's three percent slower than it should be says nothing — until one Tuesday your database is timing out, your load average is 40, and every one of those 40 processes is blocked waiting for the same tired drive to answer. Disk problems hide. They don't burn hot; they wait. That's why two of the most important problem pages in this whole knowledge base are about storage: disk full, the space emergency, and failing disk, the hardware one. Both are quiet right up until they aren't.

And the disk is the one component you genuinely cannot lose. A crashed process restarts. A full memory bank gets freed. A saturated network link clears. But a dead disk takes your data with it — and unless you planned ahead with RAID for redundancy and real off-machine backups, "planned ahead" is the only thing standing between a routine hardware failure and a very bad week. Everything else in the server is replaceable in minutes. The bytes on the disk are not.

How Linux Sees a Disk

Here's the first thing that trips up a sharp programmer landing on a server: in Linux, a disk is a file. Not metaphorically — literally a file, sitting in /dev, that you can open, seek into, and read bytes from. List them and they're right there:

ls -l /dev/sd* /dev/nvme* /dev/vd* 2>/dev/null

brw-rw---- 1 root disk   8,  0 Jun 12 09:14 /dev/sda
brw-rw---- 1 root disk   8,  1 Jun 12 09:14 /dev/sda1
brw-rw---- 1 root disk 259,  0 Jun 12 09:14 /dev/nvme0n1
brw-rw---- 1 root disk 259,  1 Jun 12 09:14 /dev/nvme0n1p1

That leading b is the tell. Most files start - (regular) or d (directory); these start b, for block device. The two numbers where a file size would normally be — 8, 0 — are the major and minor numbers, the kernel's internal coordinates for which driver owns the device and which specific unit it is. This is the abstraction the whole storage stack rests on, and it deserves a sentence of care, because "disk" and "block device" get used interchangeably and they are not the same thing.

A disk is the device — the physical drive, or the virtual one a hypervisor hands you. A block device is how the kernel talks to it: a uniform interface that presents any storage as a long array of fixed-size blocks (512 bytes or 4 KiB), addressable by number, readable and writable in those block-sized chunks. The kernel doesn't care whether the blocks live on spinning rust, flash, a RAID array, an LVM volume, or a file on another server. It speaks one language — "give me block 81,920" — and a driver underneath translates that into platter seeks or flash-page reads or network requests. The disk is the noun; the block device is the verb. When you read /dev/sda, you're not touching the hardware; you're talking to the block layer, and it touches the hardware. That indirection is the reason the same mount command works on a laptop SSD and a cloud volume sitting in another building.

Reading the Device Names

The names look cryptic until you know the grammar, and then they read like a sentence:

Name	What it is	The story behind the name
`/dev/sda`, `/dev/sdb`	SATA/SAS/USB disks	scsi disk a — the first such disk. `sda` is disk 1, `sdb` disk 2, and so on. The "scsi" is historical: modern SATA and USB drives are driven through the kernel's SCSI subsystem even though they aren't SCSI hardware.
`/dev/sda1`, `/dev/sda2`	Partitions on `sda`	A trailing number is a slice of the disk. `sda` is the whole drive; `sda1` is its first partition.
`/dev/nvme0n1`	NVMe SSD	nvme0 = first NVMe controller, n1 = namespace 1 on it. NVMe drives expose "namespaces" (usually just one), which is why they get a longer name than a plain disk.
`/dev/nvme0n1p1`	Partition on an NVMe disk	Note the `p` before the number — `nvme0n1p1`, not `nvme0n11`, because without the `p` you couldn't tell namespace 11 from partition 1.
`/dev/vda`, `/dev/vdb`	Virtio disk (a VM)	virtio disk a. Seeing `vd` instead of `sd` is a dead giveaway you're inside a virtual machine using the paravirtualised `virtio` driver.

Pro Tip

Don't trust /dev/sda to mean the same physical drive after a reboot. Device letters are assigned in the order the kernel discovers the drives at boot, which can shuffle when you add hardware or a controller enumerates differently. When it matters — pulling a failed disk, writing a dd image — identify the drive by its stable serial or UUID (lsblk -o NAME,SERIAL,UUID), never by its letter. The letter is a nickname, not an identity.

The one tool that turns all of this into a clear picture is lsblk, which draws the whole storage tree — disks, their partitions, and where each is mounted — in one glance:

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT

NAME        SIZE TYPE FSTYPE MOUNTPOINT
sda         480G disk
├─sda1      512M part vfat   /boot/efi
├─sda2        2G part ext4   /boot
└─sda3    477.5G part ext4   /
nvme0n1     1.9T disk
└─nvme0n1p1 1.9T part xfs    /var/lib/data

Read it top-down: a disk, then the partitions carved out of it, then the filesystem on each partition and where it's mounted into the tree. That picture — device, partition, filesystem, mount point — is the entire stack, and once it clicks, storage stops being mysterious.

What Sits On a Disk

A raw disk is just a numbered array of blocks — capacity with no structure, like a warehouse with no shelves. Three layers turn it into something you can store files on, and they stack in a fixed order.

First, partitions. A partition is a contiguous slice of the disk's blocks, declared in a small table at the very front of the drive (a GPT or, on old systems, an MBR). Partitioning lets one physical disk pretend to be several independent ones: a small /boot partition, a big root partition, maybe a separate one for data so a runaway log file can't fill the disk your OS lives on. The table is tiny — a few kilobytes — but it's load-bearing: corrupt it and the disk full of perfectly good data suddenly looks blank, because nothing knows where anything starts.

Second, a filesystem. A partition is still just blocks; a filesystem is the bookkeeping that turns blocks into files and directories — names, sizes, permissions, timestamps, and the map of which blocks belong to which file. On Linux this is usually ext4 or XFS; each is a different scheme for the same job. You create one with mkfs and the filesystem writes its structures (the superblock, the inode tables, the free-space maps) into the partition. Until then, the partition is a furnished-but-empty room; the filesystem is the filing system that makes it usable.

Third, mounting. Linux has no drive letters. Instead, a filesystem is grafted onto the single unified directory tree at a mount point — /, /boot, /var/lib/data in the lsblk output above. Mount nvme0n1p1 at /var/lib/data and from then on, writing to /var/lib/data/db.sqlite lands bytes on that NVMe drive, transparently. The disk vanishes into the tree; you just see paths. This is the "everything is a file, and the whole machine is one tree" philosophy made concrete — and it's why moving data to a faster disk can be invisible to the application: same path, different hardware underneath.

Sometimes a layer or two gets inserted between partition and filesystem — LVM for flexible volumes you can grow and shrink, RAID for redundancy across several disks, encryption for confidentiality. Each is just another block device stacked on a block device, which is exactly why the abstraction is so powerful: a filesystem doesn't know or care whether the blocks beneath it are a raw partition or a RAID 6 array spanning eight drives. It asks for block 81,920 and gets it. The whole tower is built from one repeated idea.

The Three Families

Almost every disk you'll meet on a server belongs to one of three families, and the speed gap between them is not incremental — it's three orders of magnitude from top to bottom. Knowing which family you're on changes what "the disk is slow" even means.

	Spinning HDD	SATA/SAS SSD	NVMe SSD
What it is	Magnetic platters spinning under a moving head	Flash chips behind the old SATA disk interface	Flash chips wired straight into PCIe
Moving parts	Yes — a head that physically seeks	None	None
Random read latency	~5–10 ms	~0.1 ms	~0.02–0.05 ms
Throughput	~150–250 MB/s	~500 MB/s (SATA-capped)	2,000–7,000 MB/s
Random IOPS	~100–200	~50,000–100,000	200,000–1,000,000+
Cost per TB	Cheapest	Middle	Priciest (closing fast)
Best for	Bulk capacity, backups, cold data	General-purpose server storage	Databases, busy VMs, anything latency-sensitive

The key to this table is the random latency row, and it's where the families truly part ways. A spinning HDD has to physically move a head to the right track and then wait for the platter to rotate the data under it — a mechanical dance measured in milliseconds, which in CPU terms is an eternity (a modern core executes tens of millions of instructions in the time one HDD seek completes). That's why an HDD is great at reading a large file in one long sweep but collapses under a database's scattered, random little reads: every seek pays the mechanical tax again. An SSD has no head to move — any block is equally close — so random and sequential access cost roughly the same, and "the disk can't keep up with the database" mostly stops being a sentence anyone says.

The split between the two SSD types is subtler and worth understanding, because it's a wiring story, not a chip story. A SATA SSD and an NVMe SSD can use identical flash; the difference is the road the data travels. SATA was designed in 2003 for spinning disks, and its protocol assumes a slow mechanical device with one request in flight at a time — a single-lane country road. It caps out around 600 MB/s no matter how fast the flash behind it is. NVMe threw that legacy away and bolts the flash straight onto the PCIe bus the GPU uses, with deep parallel queues built for chips that can serve thousands of requests at once — a sixteen-lane motorway. Same flash, wildly different ceiling, purely because of the interface it speaks through. It's one of the cleaner illustrations in computing of how an abstraction designed for old hardware can throttle new hardware long after the old hardware is gone.

Note

"SSD" and "NVMe" aren't a pair of opposites — an NVMe drive is an SSD. The real distinction is the interface: an SSD can speak SATA (slow, legacy, cheap) or NVMe (fast, modern, PCIe). When someone says "we need NVMe," they mean the fast interface, not a different storage medium.

Disks That Aren't Disks

If your server runs in a cloud or on a virtual machine, there is, somewhere, no disk that looks like the one you're using. What the OS sees as /dev/vda — a clean, simple 80 GB block device — is an illusion the hypervisor maintains. Behind it might be a slice of a giant SSD array three racks away, replicated across a datacenter, reached over the network, and presented to your VM as if it were a plain local drive bolted to the motherboard. The guest can't tell the difference, and that's the entire point of virtualisation: the abstraction is so clean the illusion is total.

This is where the block-device idea pays its biggest dividend. Because the kernel only ever speaks "give me block N," the thing answering can be anything that can fulfil that request — a real drive, a qcow2 file on the host, a logical volume, a network storage system like Ceph or a cloud provider's block service. The virtio driver (the vd* in your device names) is a thin, fast pipe between guest and host built precisely for this, skipping the pretence of emulating a real SATA controller and just shuttling block requests across the boundary. Your filesystem, your mount, your df — all of it works identically, because all of it was only ever talking to the block layer anyway.

The practical catch: on a virtual disk, performance is a policy, not a property. A physical NVMe drive is fast — that's physics. A cloud volume is as fast as your provider decided your tier should be, and they meter it: a small volume often comes with a small IOPS budget, and when you blow through that budget your blazing flash storage suddenly behaves like a tired spinning disk, throttled on purpose. New admins hit this constantly — "we're on SSD, why is the database slow?" — and the answer isn't the hardware, it's the invoice. The disk under you may be wonderful; your allowance of it may not be.

Capacity vs Performance

When people say "the disk," they're usually smearing together two completely separate questions, and untangling them is half of all storage troubleshooting.

Capacity is how much it holds — gigabytes, terabytes. This is the disk full axis. You read it with df, which shows used and free space per mounted filesystem, and it has nothing whatever to do with speed. A disk can be 99% full and lightning fast, or 5% full and crawling. Filling up causes its own distinct class of failure — services that can't write, logs that can't rotate, databases that refuse new rows — but it is a space problem, not a speed problem, and confusing the two sends you down the wrong path.

Performance is how fast it answers, and it splits into three numbers that you must keep separate:

Latency — how long a single request takes to come back, measured in milliseconds (HDD) or microseconds (NVMe). This is the one that makes a server feel slow. A database doing many tiny dependent reads lives or dies on latency.
IOPS — Input/Output Operations Per Second: how many separate little requests the disk can satisfy each second. This is what matters for the small, scattered, random access pattern of databases, busy mail spools, and virtualisation. The number that separates an HDD (hundreds) from an NVMe (hundreds of thousands).
Throughput — raw megabytes per second when you move data in big sequential chunks. This is what matters for copying a huge file, streaming a backup, or a sequential table scan. The figure that gets quoted on the box.

Here's the trap, and it's the most expensive misunderstanding in storage: a disk can have huge throughput and terrible IOPS, or vice versa. A spinning HDD can stream 200 MB/s of one big file beautifully (great throughput) while choking on a database's random reads (dreadful IOPS), because every random read forces a fresh mechanical seek. The number on the marketing sticker is throughput, because it's the big impressive one — but the number that's actually killing your database is IOPS, which the sticker rarely mentions. The first time you grasp that one disk has two different speeds depending on how you ask it for data, a great deal of mysterious server behaviour suddenly makes sense.

Pro Tip

When a server feels slow and you suspect storage, look at iowait before you blame the disk. If your CPUs are spending real time in iowait — idle but blocked, waiting on the block layer to answer — that's the smoking gun that processes are stalled on storage, not starved of CPU. Iowait near zero on a slow server means look elsewhere; iowait high means the disk genuinely can't keep up, and now you measure latency and IOPS to find out why.

And this is the most common wrong diagnosis a new admin reaches for: "everything's slow, we need a bigger disk." Bigger usually means more capacity, which does nothing for speed. If the problem is IOPS, you don't need a roomier disk — you need a faster kind of disk (HDD → SSD → NVMe), or in the cloud, a higher performance tier. Size and speed are different dials. Reach for the right one.