One Layer Down — a dying disk, a silent decision, and what the machine knew but never told me.
Last time I left off with three words — running, ready, blocked — and one question I’d never thought to ask about a frozen screen: was my CPU overloaded with things it couldn’t get through, or was it sitting idle with nothing it was allowed to run?
The answer comes down to a single rule, and it’s the rule that quietly reorganized how I think about stalls: the scheduler can only pick from the ready ones.
A blocked thread isn’t in the running. It can’t be handed the CPU no matter how idle the CPU is, because it has nothing to do until the thing it’s waiting for arrives. It just sits off to the side until the world taps it on the shoulder and says okay, your data’s here, you can get back in line.
The scheduler doesn’t forget it or neglect it. It simply can’t run a thread that isn’t runnable. That’s not a flaw. That’s the scheduler being correct.
And once you hold that rule up against a freeze, the freeze explains itself — almost gently.
When your program reads a file, that thread goes blocked while the disk fetches the data, then wakes up when the data arrives. On a healthy drive that round trip is a fraction of a millisecond. You’d never feel it, and meanwhile the scheduler is happily running everything else. The abstraction reading a file is basically instant holds, so you never once think about it.
My drive was dying. And a dying drive doesn’t fail cleanly — it retries. It attempts a read, the data comes back wrong, it tries again, and again, timing out slowly before it either scrapes the data together or gives up. For every one of those seconds, the thread that asked is blocked. It cannot run. And it doesn’t matter in the slightest how fast or fair the scheduler is, because there is nothing to schedule that thread onto until the disk finally answers.
Then the rest falls like dominoes. On a modern machine an enormous number of threads touch the disk, directly or not — your editor autosaving, the OS paging code in and out, background services writing their logs. One by one they reach for that dying drive, go blocked, and stay blocked. The ready line drains.
And you land on the exact, strange thing a freeze actually is: a perfectly working CPU, a perfectly working scheduler, and almost nothing in the ready line to run. The processor isn’t drowning. It’s idle — sitting there while everything that wants to run is stuck waiting on a piece of failing hardware a layer beneath it.
So the thing I’d blamed all along was the one innocent party in the room. The scheduler never failed. It did its job flawlessly, right up to the end — correctly refusing to run threads that genuinely could not run. I’d accused it because “scheduler” was the deepest word I owned, and when you only have one word, everything looks like that word’s fault.
There’s a second, meaner version of this, and it’s worth knowing because it turns a slow disk into a spiral. When memory fills up, the OS starts paging — shoving chunks of RAM out to disk to free up room, then reading them back when they’re needed again. Onto which disk? The dying one.
So a low-memory moment tries to page to a drive that’s already timing out, which blocks, which makes everything slower, which fills memory faster, which forces more paging. The disk and the memory take turns making each other worse, and from the outside it’s still just a frozen screen. Same symptom, deeper hole. Not the CPU failing — everything downstream of it waiting on a component that stopped keeping time.
That’s the mechanism, and honestly, understanding it was a relief. But it’s not the part that stuck with me.
The part that stuck with me is what I didn’t have while it was happening. For months I sat in front of that frozen screen inventing theories, and the whole time the computer knew exactly what was wrong. It had the ground truth sitting right there in its own bookkeeping: this thread is blocked on I/O to this device, and that device has been timing out and retrying for four seconds. The fact existed. It just never travelled the last few inches to the one place it would have mattered — the person at the glass.
And the more I sat with that, the more it started to feel like the real bug wasn’t the disk at all. Disks die. That’s honest; that’s physics, and we’ll get to physics later in this series. The thing I’d actually want to argue about — over that coffee, with someone who knows this better than me and might talk me out of it — is the silence.
Think about where we’ve spent our effort. The scheduler is a genuinely beautiful piece of engineering. Decades of careful work went into making it fair, preemptive, efficient — into that seamless illusion of everything running at once. We poured enormous care into the machinery. And we poured almost none of it into making the machine honest with the person using it when something underneath quietly breaks. The moment an abstraction leaks, the system’s instinct is to go quiet and keep trying, not to turn around and tell you what it’s struggling with.
So here’s the thing I keep turning over: why can’t it just say so?
If threads are stacking up blocked on one specific device, and that device has been timing out for seconds, the computer already has everything it needs to tell me. It wouldn’t take a smarter scheduler or new hardware. It would take a system that, under duress, degrades toward honesty instead of toward silence. Not a cryptic error. Just the truth, in a sentence: waiting on Disk 0, which isn’t responding. That one line would have collapsed months of wrong theories into a single correct thought, and I’d have known to back up my files and replace the drive long before it took my data with it.
Now, I can argue the other side, because it’s a real argument and I don’t want to pretend it isn’t. Systems are built to retry-and-wait for good reasons. Most slow disk reads aren’t a dying drive — they’re a drive that’s briefly busy, and it recovers in a moment. If the machine panicked and started shouting every time a read took a beat too long, you’d have a computer that cries wolf constantly, and you’d learn to ignore it, which is worse than silence.
There’s a genuine tension here between staying responsive and actually finishing the work you asked for — between failing fast and being patient. Retry-and-wait is the system quietly choosing patience on your behalf.
But that’s exactly my discomfort. It’s choosing for me, silently, every single time — always in the disk’s favor, never in mine, and it never even tells me the choice is being made. I’m not sure the right answer is “fail fast.” I’m fairly sure the right answer is “don’t decide this in the dark.” A system that noticed this device has been unhealthy not for one read but for minutes, across dozens of threads has crossed the line from “briefly busy” into “something is actually wrong here.”
And at that line, patience without a word to the user stops being a kindness.
That’s the design I’d want to build toward. And I’d genuinely like to hear why I’m wrong, because someone reading this probably has a good reason I haven’t thought of.
Either way, the freeze left me with a habit I still use every week, and it has nothing to do with laptops. When something stalls — a request, a job, a whole service — my first question is no longer who’s running too much. It’s what is this waiting on? Frozen almost never means overwhelmed. It nearly always means something is blocked on a layer below the one I was staring at. The exact shape of my dying laptop shows up again and again in production systems, and now I recognize it on sight.
Which is the whole reason for this series. My laptop took a few months to die, and it didn’t go all at once — it failed at every layer of the machine, one at a time, and each failure was an uninvited lesson about a part of the system I normally never think about, because I live up top where things just work.
Next, it stops being polite about it. The freezes were the OS quietly failing to run things. The blue screen is the OS deciding it can no longer safely run anything — and choosing, on purpose, to stop the world. That’s a decision, made by a specific layer, for a specific reason. So we go one more layer down and meet the part of the system that gets to make it.