SSD Scheduling Considerations vs Hard Disks
Learn SSD scheduling considerations vs HDDs — queue depth, write amplification, and NVMe parallelism — OS interview questions answered.
Expected Interview Answer
Because SSDs have no moving read/write head, seek-minimizing algorithms like SCAN or SSTF give little benefit and can even hurt performance, so OS I/O schedulers for SSDs instead focus on request merging, queue depth exploitation, wear leveling awareness, and fairness — which is why Linux defaults SSDs to simpler schedulers like none/noop or mq-deadline rather than elevator-style ones.
A spinning disk pays a real physical cost to move the head between tracks, so ordering requests to minimize seek distance (SCAN, SSTF, LOOK) produces a large real speedup; an SSD has uniform, near-constant access latency across its whole address space regardless of the logical block requested, so reordering purely for locality buys almost nothing and the CPU cycles spent sorting requests become pure overhead. What does matter for SSDs is exploiting the device’s internal parallelism — modern NVMe SSDs expose many hardware queues and can service dozens of requests concurrently across flash channels, so a scheduler that dispatches many requests at once (high queue depth) achieves far higher throughput than one that waits for each request to complete before issuing the next, which is why simple 'none'/noop schedulers that just merge adjacent requests and pass them straight to the device often outperform elevator algorithms for NVMe SSDs. The other SSD-specific concern is write amplification and wear leveling: because flash cells wear out after a limited number of program/erase cycles and writes must first erase a whole block, the scheduler and underlying flash translation layer benefit from batching and aligning writes to erase-block boundaries rather than optimizing for seek distance, which does not exist for flash at all.
- Avoids wasted CPU cycles reordering requests for a seek cost that does not exist on flash
- Exploits NVMe multi-queue parallelism for much higher throughput
- Reduces write amplification by batching writes to erase-block boundaries
- Explains why Linux uses none/mq-deadline for SSDs instead of CFQ or BFQ elevator schedulers
AI Mentor Explanation
Scheduling for a spinning disk is like carefully planning a groundsman’s walking route around one huge ground to minimize backtracking, because physically walking between spots costs real time. Scheduling for an SSD is like having a whole squad of groundstaff each instantly teleport to their own assigned spot at once, so there is no walking distance to optimize and route-planning effort is wasted. What actually matters for the squad is dispatching many of them simultaneously rather than one at a time, and batching their repair work into full sections rather than tiny scattered patches, mirroring how SSD scheduling favors parallel dispatch and erase-block-aligned writes over seek minimization.
Step-by-Step Explanation
Step 1
Recognize uniform access latency
The scheduler must know the device has no mechanical seek cost, so locality-based reordering provides little benefit.
Step 2
Exploit queue depth
The scheduler dispatches many requests concurrently across the NVMe device's multiple hardware queues instead of one at a time.
Step 3
Merge adjacent requests
Adjacent logical blocks are still merged into larger I/Os to reduce per-request overhead, which helps both HDDs and SSDs.
Step 4
Respect erase-block alignment
Writes are batched and aligned to flash erase-block boundaries to reduce write amplification and wear.
What Interviewer Expects
- Understanding that SSDs have no mechanical seek cost, unlike HDDs
- Explaining why elevator algorithms (SCAN/SSTF) add little value for SSDs
- Awareness of NVMe multi-queue parallelism and its throughput benefit
- Mentioning write amplification / wear leveling as an SSD-specific concern
Common Mistakes
- Applying SCAN/SSTF reasoning to SSDs as if seek time still mattered
- Not knowing Linux defaults to none/mq-deadline for SSDs, not CFQ
- Ignoring NVMe queue depth as a major throughput lever
- Forgetting that flash writes require erasing whole blocks first, unlike HDD sectors
Best Answer (HR Friendly)
“Hard disk scheduling is all about minimizing how far a physical head has to move, but an SSD has no moving parts and roughly the same access time no matter where the data sits, so that kind of route-planning barely helps and can even waste CPU time. What actually speeds up an SSD is sending many requests to it at once so it can work on them in parallel, and being smart about how writes are batched, since flash memory has to erase a whole block before rewriting it and wears out after enough cycles.”
Code Example
#define MAX_QUEUE_DEPTH 32
struct io_request { unsigned lba; unsigned len; void *buf; };
void submit_ssd_requests(struct io_request reqs[], int n) {
int outstanding = 0;
for (int i = 0; i < n; i++) {
/* No seek-distance sorting needed: flash access latency is
roughly uniform, so dispatch order does not matter much. */
nvme_submit_async(&reqs[i]);
outstanding++;
if (outstanding >= MAX_QUEUE_DEPTH) {
nvme_wait_for_any_completion(); /* drain one slot before submitting more */
outstanding--;
}
}
nvme_wait_for_all_completions();
}Follow-up Questions
- Why does Linux use the none/noop scheduler by default for NVMe SSDs?
- What is write amplification and why does it matter for SSD longevity?
- How does the flash translation layer relate to wear leveling?
- Why does NVMe queue depth matter more for throughput than request ordering?
MCQ Practice
1. Why do seek-minimizing algorithms like SCAN provide little benefit on SSDs?
Since flash access latency does not depend on physical head movement, reordering requests for locality does not produce the seek-time savings it does on a spinning disk.
2. What SSD-specific throughput lever matters more than request ordering?
NVMe SSDs can service many requests concurrently across hardware queues and flash channels, so dispatching at high queue depth drives much higher throughput than careful ordering.
3. What is write amplification in the context of SSD scheduling?
Because flash must erase a whole block before rewriting any part of it, small or misaligned writes can trigger extra internal read-erase-write cycles, amplifying wear.
Flash Cards
Why is SCAN/SSTF less useful for SSD scheduling? — SSDs have no moving head and roughly uniform access latency, so seek-minimizing reordering buys little.
What SSD throughput lever matters most? — Exploiting NVMe multi-queue parallelism by dispatching many requests concurrently (queue depth).
What is write amplification? — Extra internal flash writes beyond what was requested, caused by erase-block granularity and misaligned writes.
What Linux I/O scheduler is typically used for NVMe SSDs? — none/noop or mq-deadline, rather than elevator algorithms like SCAN-based CFQ/BFQ.