Here's a weird fact about the SSD in your laptop: just reading data from it can corrupt nearby data. This is called "read disturbance," and it's a known quirk of NAND flash memory. Every time you read a page of flash, the electrical operation slightly disturbs the charge in neighboring cells. Do it enough times, and those neighbors accumulate bit errors.

Chip vendors have known about this for years and built countermeasures inside the SSD's firmware — mainly, when a page has been read too many times, the controller quietly copies its neighborhood to a fresh location before errors pile up. This is called a "read-reclaim." From the outside, everything looks fine. Your reads succeed. Your data is intact.

But this paper asks a question almost nobody has measured carefully: what does all that behind-the-scenes rescue work do to system performance? The authors run real workloads on real modern SSDs and find some genuinely uncomfortable answers.

The key findings:

• Read-heavy workloads can slow themselves down. Ironically, the more you read the same hot data, the more read-reclaim work the SSD has to do in the background, which competes with your actual I/O for the flash channels.
• Latency spikes are unpredictable. A read that normally takes ~100 microseconds can occasionally balloon into milliseconds when it collides with a reclaim operation. For latency-sensitive systems (databases, key-value stores, real-time analytics), those tail latencies are exactly what breaks SLAs.
• Denser flash makes it worse. As vendors cram more bits per cell (TLC, QLC) to grow capacity, the cells get more sensitive to disturbance, and the reclaim overhead grows.
• The problem is invisible to the OS. Linux, filesystems, and databases have no idea any of this is happening. They just see occasional weirdness in latency and can't schedule around it.

The authors argue this changes how we should think about storage design. If SSD firmware is silently doing more and more housekeeping work as densities climb, then the OS and applications need visibility into it — the ability to know when reclaim is coming, or to hint at which data is hot, so background work can be scheduled during quiet moments instead of stomping on critical queries.

It's a great example of an "abstraction leak": the SSD pretends to be a simple block device, but underneath, physics is intruding on that clean interface in measurable ways.