the block I/O layer (the bio/request)

Between the filesystem (which thinks in files and offsets) and the actual storage device (which thinks in raw sectors) sits a piece of the kernel whose whole job is to turn 'read these file blocks' into concrete, efficient device operations. It collects the requests, merges and orders them, and hands them to the driver. That middle machinery is the block I/O layer, and its central data structures are the bio and the request.

Here is the flow. When the page cache needs to read or write actual disk blocks, it submits a bio - a structure describing one I/O operation: a direction (read or write), a target device, a starting sector, and a list of memory pages to fill or drain (a scatter-gather list, so one logical transfer can span several non-contiguous memory pages). The block layer takes these bios and assembles them into requests on a queue. Before issuing, it does two clever things: merging (if two pending bios touch adjacent sectors, fuse them into one larger request so the device does one big transfer instead of two small ones) and sorting/scheduling (decide what order to send requests in). On modern Linux this is the multi-queue block layer (blk-mq), which gives each CPU its own submission queue so many cores can submit I/O in parallel without fighting over one lock - essential for fast SSDs and NVMe drives that can handle huge numbers of concurrent operations.

Why it matters: the block layer is where I/O becomes efficient - merging and ordering can turn a storm of tiny scattered requests into a few large sequential ones, which matters enormously for throughput. The honest framing: it abstracts away whether the device underneath is a spinning disk, a SATA SSD, an NVMe drive, or a network block device, presenting all of them as a numbered array of fixed-size sectors. The old single-queue design became a bottleneck precisely because one lock could not keep a million-IOPS NVMe device busy, which is the whole reason blk-mq exists.