Bogus article. They didn't write anything to the drive, they faked writes to run up the drive's write counter to test whether the controller would declare the drive worn out despite the flash not being touched.
Yes, even the video's thumbnail explains this, I'm not sure how the article author managed to get it so badly wrong. (Although I'm not sure why it would need a windows bug, surely it's more of a drive firmware bug?)
These tests are quite misleading as they typically (didn't find any details) just go through the entire drive writing to it evenly. Which, to be fair is probably not that bad of a test unless you have intimate knowledge about how the controller operates.
But it means that every single cell gets even use and there are no write amplification and it doesn't expose controller or usage characteristics.
Depending on use it will most likely fail way earlier under more normal conditions. Not saying that filling a drive time and time again is completely abnormal, but it the nicest thing you can do to an ssd in many aspects.
This actually isn't even writing data to the disk, it's exploiting a bug in the Windows 11 storage subsystem to run up the drive's firmware's count of bytes written without performing any actual writes in order to disprove the myth that SSD firmware is programmed to self-destruct when the endurance rating is reached.
This is detailed in the thumbnail of the YouTube video embedded about halfway through the article.
Wouldn't the firmware on the drive typically ensure that it's written to evenly regardless of write pattern? If you repeatedly delete/update the 'same' logical block address on the drive, that won't actually correspond to the same physical location.
It will try to do that yes, but there are consequences, drawbacks and imperfections.
You can only cheaply do so with free blocks, and if 70% is occupied you can only spread it out over the remaining 30%. After you've done that for a while you'll have to rearrange existing data which incurs more writes and less performance. And fragmentation is still an issue.
There are tons of tradeoffs - which will be better or worse for different workloads. But to assume that it wear perfectly, which most people seem to do because it is easy, isn't particularly realistic.
That’s why SSDs have overprovisioning, more so for enterprise drives. And why TRIM is important. That being said most workloads are sequential, particularly retail usage. Much easier to deal with for the controller than enterprise workload ratings that assume 4k random writes
The drive internally usually stores data in blocks larger than the 4k blocks it pretends to use to the OS (say it uses 16k blocks internally). So if your writes are sequential, it will most likely write the same 16k block in one go. If you write random 4k blocks, it will have to rewrite a full 16k block for every 4k block you write, hence write amplification.
So if you fill the drive over and over using sequential writes you can expect way more endurance than if you write random blocks.
>However, this particular case was pretty interesting, given that it was on an older drive with MLC NAND that has since disappeared from the market.
Much less surprised after reading this; MLC is quite durable. Not as much as SLC, but still much better than TLC or, heaven forbid, QLC flash (which is trash).
For more serious information, in my work PC I have a cache SSD which is a 2009 Intel 32GB, it got more than 46 TB of writes over 67000 hours of uptime, and is still working fine.
Bogus article. They didn't write anything to the drive, they faked writes to run up the drive's write counter to test whether the controller would declare the drive worn out despite the flash not being touched.
Yes, even the video's thumbnail explains this, I'm not sure how the article author managed to get it so badly wrong. (Although I'm not sure why it would need a windows bug, surely it's more of a drive firmware bug?)
The article was written, from soup to nuts, by AI. I suspect the person who threw his byline on it barely glanced at the text.
These tests are quite misleading as they typically (didn't find any details) just go through the entire drive writing to it evenly. Which, to be fair is probably not that bad of a test unless you have intimate knowledge about how the controller operates.
But it means that every single cell gets even use and there are no write amplification and it doesn't expose controller or usage characteristics.
Depending on use it will most likely fail way earlier under more normal conditions. Not saying that filling a drive time and time again is completely abnormal, but it the nicest thing you can do to an ssd in many aspects.
This actually isn't even writing data to the disk, it's exploiting a bug in the Windows 11 storage subsystem to run up the drive's firmware's count of bytes written without performing any actual writes in order to disprove the myth that SSD firmware is programmed to self-destruct when the endurance rating is reached.
This is detailed in the thumbnail of the YouTube video embedded about halfway through the article.
Wouldn't the firmware on the drive typically ensure that it's written to evenly regardless of write pattern? If you repeatedly delete/update the 'same' logical block address on the drive, that won't actually correspond to the same physical location.
It will try to do that yes, but there are consequences, drawbacks and imperfections.
You can only cheaply do so with free blocks, and if 70% is occupied you can only spread it out over the remaining 30%. After you've done that for a while you'll have to rearrange existing data which incurs more writes and less performance. And fragmentation is still an issue.
There are tons of tradeoffs - which will be better or worse for different workloads. But to assume that it wear perfectly, which most people seem to do because it is easy, isn't particularly realistic.
That’s why SSDs have overprovisioning, more so for enterprise drives. And why TRIM is important. That being said most workloads are sequential, particularly retail usage. Much easier to deal with for the controller than enterprise workload ratings that assume 4k random writes
Yes? Not sure what your point is.
Sequential workloads and just filling the drive over and over are very different still.
The drive internally usually stores data in blocks larger than the 4k blocks it pretends to use to the OS (say it uses 16k blocks internally). So if your writes are sequential, it will most likely write the same 16k block in one go. If you write random 4k blocks, it will have to rewrite a full 16k block for every 4k block you write, hence write amplification.
So if you fill the drive over and over using sequential writes you can expect way more endurance than if you write random blocks.
Yes, that was one of my points in my first post...
I also jhave 16 year old X25-M 120GB thats still going strong nowhere near as much writes though
I have an old sata SSD that's been my write cache and transcoding drive for 8 years. Will check the tbw
Sequential vs random writes make a world of difference.
Post what cell tech do it have
Probability SLC drives are better in that regard
TBW ratings are notoriously conservative. People have been writing well past a petabyte to consumer drives for years before they give out.
>However, this particular case was pretty interesting, given that it was on an older drive with MLC NAND that has since disappeared from the market.
Much less surprised after reading this; MLC is quite durable. Not as much as SLC, but still much better than TLC or, heaven forbid, QLC flash (which is trash).
For more serious information, in my work PC I have a cache SSD which is a 2009 Intel 32GB, it got more than 46 TB of writes over 67000 hours of uptime, and is still working fine.
[dead]