the I/O scheduler

When many programs want disk I/O at once, the block layer holds a queue of pending requests, and someone must decide the order to send them to the device. On a spinning disk that order matters enormously, because moving the head across the platter is the slow part - servicing requests in a smart order instead of arrival order can cut seek time dramatically. The component that chooses that order, and decides which request goes next, is the I/O scheduler.

The classic insight is the elevator analogy: a lift does not zigzag to every floor in the order buttons were pressed; it sweeps up servicing requests on the way, then sweeps down, minimizing travel. Old disk schedulers (the elevator/CFQ family) sorted requests by sector to minimize head seeks. Modern Linux multi-queue schedulers serve different goals: mq-deadline keeps requests sorted but attaches a deadline to each so no request starves while the head chases a busy region, balancing throughput against latency; BFQ (Budget Fair Queueing) gives each process a fair share of disk bandwidth and protects interactive responsiveness, so a big background copy cannot freeze your desktop; and the none scheduler does essentially nothing - just FIFO - which is often best for very fast NVMe SSDs where reordering buys nothing and the scheduler's own work would only add latency.

Why it matters: on rotating media the right schedule is the difference between near-streaming throughput and thrashing the head back and forth. The honest update for modern hardware: SSDs and NVMe have no seek penalty - any block is equally fast - so the elaborate seek-minimizing logic that helped spinning disks can actually hurt, adding CPU overhead and latency for no benefit. That is why fast flash devices commonly run the none (or a very light) scheduler, and why the best scheduler genuinely depends on whether your device has a moving head at all.