When Microsoft introduced Windows 10 2004 earlier this year, it shipped an errata that may have shortened your SSD’s longevity depending on how often you reboot your machine. The good news is that a fix is on the way and that the problem shouldn’t have caused too many problems between now and when the update dropped, unless you reboot your PC (and pollute your SSD) much, much more than your typical Windows user.
First, here’s the description of the bug itself: Windows 10 2004 shipped with a problem in which the system stopped recording the time since the SSD had last been defragged. Reboot your machine, and the OS forgets how long it’s been and will promptly launch defrag attempts again. This has been treated as potentially causing damage to a solid state drive, and I’m not going to claim it couldn’t, but the chance of this causing meaningful problems is unlikely. Here’s why: While it’s true that defragging an SSD every time you reboot isn’t great for it, SSDs are just like hard drives in one regard: The more often you defrag them, the less work each individual defrag session has to do.
Image shows Windows 10 2004. Image by BleepingComputer
This doesn’t mean the drive isn’t being exercised unnecessarily, but the amount of NAND flash that’s likely to be getting exercised in any given defrag session is going to be small. Several publications have implied that these extra defrags constitute “slowly killing” the drive, but by this interpretation, so is every single write operation. If you reboot your machine every single day, your SSD has been defragged a few dozen more times than necessary. If you are like most people with a reasonably stable computer these days and you reboot only when necessary — my own last reboot was about two weeks ago — then your drive has been defragged a bare handful of times more than it otherwise would have been.
When SSDs first began to arrive in-market, this kind of caution was much more important. Operating systems like Windows Vista didn’t support features like TRIM natively, and we regularly recommended that people use features like Secure Erase under Linux to reset drives to full factory performance in-between OS installs or even after heavy usage. Because drives were much smaller, the amount of wear on any given NAND cell was expected to be higher over time. The various algorithms that protect SSDs from wearing out too quickly by reducing write amplification were in their infancy. For all of those reasons, reviewers and analysts were quite careful about the risk of running out of write cycles on a drive and the associated chance of data loss.
Over a decade later, however, SSDs have not proven to have the kinds of longevity issues we once feared they might. In general, drive data retention and NAND reliability have not been problems, though obviously SSDs still fail and people have suffered data loss issues because of it. But even TLC drives have shown themselves to have good overall endurance and most people don’t reboot their computers all that much. Grab the update when it drops — reducing SSD wear-and-tear is always a good thing — but don’t sweat the idea of a bit more defragging than usual. The chances of this causing a significant problem are small. Build 19042.487 has already been fixed in the beta channel, and the same repairs are expected to roll out to 2004 users in short order.
Now Read:
- A Massive Laptop Shortage Has Hit the United States
- Microsoft Removes Option to Disable Windows Defender Antivirus
- Microsoft Deploys AI ‘Supercomputing’ via Nvidia’s New Ampere A100 GPU
No comments:
Post a Comment