← Interview Prep

Linux Kernel — Block Device Drivers

The block layer from page cache to platter: bio → request → request_queue (merge/sort/plug), single-queue vs blk-mq multi-queue, the I/O schedulers (none/mq-deadline/bfq/kyber) and why SSD/NVMe prefer none, queue knobs in /sys/block, and stacked devices (LVM/RAID/dm-crypt).

The path from a cached page to sectors on a disk — the block layer, the request queue, and the I/O schedulers that decide order. Where filesystem I/O actually meets storage. Original, interview-focused notes; builds on I/O Architecture and the Page Cache.

Above: filesystems produce I/O in units of pages/blocks. The block layer packages those into bio requests, batches and orders them in a queue, and hands them to the driver, which DMAs them to the device. Reordering/merging exists because disks reward locality — and SSDs/NVMe change that calculus.

The stack

page cache / direct I/O
      │  submit_bio()
 block layer:  bio → request → request_queue   (merge, sort, schedule)
      │
 device driver  → DMA →  disk / SSD / NVMe

A bio describes a transfer: target sectors + a list of memory pages. The block layer coalesces contiguous bios into requests and dispatches them.
Between the page cache and the device sit merging (combine adjacent I/O), sorting, and plugging (briefly hold requests to batch them).

Single-queue → blk-mq

The classic block layer had one request queue with a lock — a bottleneck on fast, parallel devices.
Modern Linux uses blk-mq (multi-queue): per-CPU software queues feed a small number of hardware queues the device exposes (NVMe has many). No single lock → millions of IOPS. This is why NVMe performance needed a new block layer.

I/O schedulers

Scheduler	Idea	Best for
none / noop	FIFO, no reordering	Fast SSD/NVMe (seeks are free; reordering just adds latency).
mq-deadline	Deadlines per request + sorting; bounds worst-case latency	General SSD/HDD; the safe default.
bfq	Budget Fair Queueing — per-process fairness & low latency	Desktops/interactive, HDDs.
kyber	Simple latency-target throttling	Fast multi-queue devices.

The key point: on a spinning disk, sorting/merging to minimize seeks is a huge win; on SSD/NVMe there's no seek, so heavy scheduling just adds overhead — hence none is often best. Set it via /sys/block/<dev>/queue/scheduler.

Knobs & observability

/sys/block/<dev>/queue/: scheduler, nr_requests (queue depth), read_ahead_kb, rotational (1 = HDD), nomerges.
Observe: iostat -xz 1 (%util, await, IOPS), blktrace/biolatency (eBPF) for per-I/O latency. See Performance Triage.
Above the device: LVM, dm-crypt, and MD RAID are stacked block devices — each a layer that remaps bios before they reach the real driver.

Likely interview questions

Trace a write from the page cache to the platter — what is a bio, a request, the queue?
Why do I/O schedulers merge and sort, and why does that matter less on SSDs? (no seeks)
Which scheduler for NVMe and why? (none/kyber — avoid reordering overhead)
What is blk-mq and what problem did it solve? (single-queue lock → per-CPU/HW queues)
How do you inspect/tune a block device? (/sys/block/.../queue, iostat)
What is plugging/merging?
How do LVM/RAID/dm-crypt fit? (stacked block devices remapping bios)

Kernel Internals series. Related: I/O Architecture · Performance Triage.