A story about an old storage device manufactured in 2010 that had allegedly kept running far beyond its rated rewrite limit—by orders of magnitude—spread rapidly online. A screenshot posted to the Reddit community r/ssd showed a SanDisk SSD with a mere 64GB of capacity that was still operating despite having recorded a cumulative total of over 9 petabytes (PB) of writes.
A figure of 9PB works out to roughly 140,000 full rewrites of the entire 64GB drive. Judging by typical SSD lifespan metrics, this looks like a number that blows past physical limits by a factor of hundreds.
But behind this figure lies a decisive gap between storage measurement metrics and hardware structure. Tracing the methodology that the person who ran this experiment revealed in detail on a technical forum shows that the physical flash memory did not miraculously demonstrate extraordinary endurance. What was actually carried out was a peculiar stress test designed to push the SSD's "brain"—its controller and firmware—to the absolute limit of its processing capability.
The "9-petabyte survival" figure that went viral online
The story originated from a post by Reddit user Fresh-Palpitation-72. Tech media outlets such as Wccftech picked it up, reporting that a 16-year-old legacy SSD had survived a brutal endurance test.
According to the published SMART (self-diagnostic) data, Attribute 9 (Power-On Hours), which indicates the drive's cumulative operating time, exceeded 61,000 hours—equivalent to roughly seven years of continuous power-on time. The Total_LBAs_Written counter, which tracks the total number of write sectors sent from the host, had surpassed 9 petabytes.
This experiment was not something that happened spontaneously. The tester, using the handle Techwolfs, had been documenting the process in detail since around July 2026 on the Level1Techs technical community forum, in a thread titled "Forced a 16 year 64gb ssd p4 sandisk from 2010 rated for 40tbw, hit 1 petabyte to pass 8 petabytes." On their own YouTube channel, WolfyTech, they also posted a video showing the drive's behavior at the earlier 1-petabyte milestone.
Media coverage often framed the story in terms of "the extraordinary endurance of early MLC flash memory." However, before taking the published numbers at face value, it's necessary to separate the identity of the hardware in question from what the tester actually did.
The SanDisk P4: an SSD built in 2010 for thin client devices
The unit under test was the 64GB model of the SanDisk SSD P4 (firmware version SSD 8.10), a modular solid-state drive that SanDisk announced on June 1, 2010, at Computex Taipei in Taiwan.
According to SanDisk's official datasheet, the P4 series belonged to a third-generation lineup of pSSD products designed at the time for netbooks, tablets, and thin embedded devices. It used a SATA II (3.0 Gbps) interface and came in compact form factors such as Half 1.8-inch and mSATA.
The flash memory was manufactured using 32nm-generation MLC (Multi-Level Cell) NAND, a structure that holds 2 bits of data per cell. The Long Term Data Endurance that SanDisk guaranteed in its datasheet for the 64GB model was 40 TBW (terabytes written).
| Item | Official specification | Surface-level figure recorded in the experiment |
|---|---|---|
| Drive capacity | 64GB | 64GB |
| Flash memory type | 32nm MLC NAND | 32nm MLC NAND |
| Interface | SATA II (3.0 Gbps) | SATA II (3.0 Gbps) |
| Rated write endurance (TBW) | 40 TBW | Over 9,000 TBW (over 9 PB) |
| Power-on hours | N/A | Over 61,000 hours (approx. 7 years equivalent) |
| Write cycle equivalent | Approx. 625 cycles (based on 40TBW) | Over approximately 140,000 cycles (host-calculated value) |
If 9 petabytes of data had actually been written directly to the physical flash memory cells, the drive would have withstood a staggering load roughly 225 times its rated endurance. But as a matter of semiconductor physics, it is engineering-wise impossible for 32nm-generation MLC cells to endure 140,000 erase-and-program cycles without dielectric breakdown. The key to resolving this contradiction lies in the structure that bypasses the actual write process.
A test method that decoupled the host counter from NAND wear
On the Level1Techs forum, the tester frankly disclosed the specific mechanism behind the test. What was being executed was not a test that ground down flash memory cells, but a processing loop that exploited the drive's internal cache layer.
The tester wrote on the forum: "I managed to get the system to funnel massive amounts of telemetry writes directly into the drive's odometer. It keeps hammering the 16-year-old controller hard, but the NAND itself never heats up. Because these are essentially virtual cache operations, the actual data vanishes without a trace before it ever physically wears down the old MLC NAND flash cells."
In this test environment, a fast macro loop running on a 5-second cycle was operated on Windows 11. Massive numbers of write commands were sent from the host PC to the drive in rapid succession, and the processing was completed within the drive's volatile DRAM cache layer. By repeatedly discarding data before it was physically committed—"flushed"—to the NAND memory blocks, only the host-facing cumulative counter, Total_LBAs_Written, was made to climb at a furious pace.
The tester themselves characterized the effort as "not a NAND wear test, but a pure endurance test of the controller and firmware's processing capability." They stated explicitly: "A lot of people run these kinds of tests to destroy the physical NAND, but what I wanted to test was the endurance of the controller and firmware's processing itself."
Reader comments on the hardware information site Tom's Hardware pointed out the same thing: "The user who ran the test built a tool that sends writes destined for the DRAM cache, which get wiped before ever reaching the NAND. Since no actual physical wear is occurring, physical degradation from NAND erase cycles is irrelevant here."
The phrase "over 140,000 rewrite cycles," which appeared in media coverage, is simply a figure derived by dividing the cumulative 9PB total sector count by the drive's logical capacity (64GB). It only represents the number of I/O transactions sent from the host to the controller—not an actual record of P/E (program and erase) cycles executed inside the NAND.
The clearest evidence backing this up is SMART Attribute 5, "Reallocated_Sector_Ct." This value remained consistently at "0" throughout the experiment, indicating that the occurrence and reallocation of bad sectors caused by physical cell dielectric breakdown were barely happening at the hardware level.
What the SMART log reveals about internal firmware breakdown
Even though the physical NAND flash escaped destruction, the controller and firmware did not come away unscathed. Prolonged, high-frequency I/O processing left definite scars on the drive's internal control logic.
A close examination of the detailed SMART diagnostic items reveals that the controller's computational processing and log management functions were reaching the limits of normal control.
| SMART attribute / metric | Recorded value | Technical interpretation of the state | Direct impact on physical NAND |
|---|---|---|---|
| Attribute 5 (Reallocated Sectors) | 0 | No bad sectors have been reallocated | Dielectric breakdown of physical cells remains minimal |
| Attribute 172 (Erase Failure / Log) | 939,410,736 | Internal controller value overflow or log corruption | Internal firmware counter management has broken down |
| Attribute 187 (Reported Uncorrect) | 2,228 | Accumulated read errors the controller could not correct | Partial failures in returning data to the host have occurred |
| Attribute 230 (Wear Indicator) | 36 / 100 | Degradation judgment from the firmware's internal wear model | Progression of estimated wear based on host-side I/O history |
| Sector 0 (LBA 0) status | UNC (unrecoverable error) | Boot area read failure; FTL and DMA remain operational | Booting from the drive alone is difficult |
| External diagnostic tool verdict | "Good" | Mechanically judged as normal based on predefined thresholds | Risk of overlooking signs of internal corruption is exposed |
Attribute 172 showed a particularly striking anomaly, recording an unnaturally huge value of "939,410,736." The tester analyzed this as corruption of the erase-failure counter or an internal numeric overflow within the controller's calculations. It appears that as the 16-year-old firmware kept processing transaction volumes far beyond anything it was originally designed to handle, the log storage area itself broke down.
An even more serious sign: Attribute 187 (Reported_Uncorrect) recorded 2,228 unrecoverable errors. In the SMART error log, an unrecoverable UNC error was recorded at LBA 0 (sector 0)—the drive's very first location—meaning reads were failing in the area containing the boot sector.
Interestingly, despite carrying these fatal errors, the FTL (Flash Translation Layer) logical-to-physical mapping, DMA transfers, and write cache functions all continued to operate. Meanwhile, the common disk diagnostic software CrystalDiskInfo kept judging the drive's health status as "Good."
The tester issued a warning about this behavior: "The data is corrupted and the drive can't read it back properly, yet the software keeps blindly shouting 'Good.' These diagnostic programs have no capacity to think—they're just mechanically following basic logic rules that were set back in 2010."
The health percentages and "normal" indicators that many users rely on cannot necessarily detect control breakdowns occurring inside the firmware. This illustrates the danger of modern monitoring tools failing to correctly interpret unexpected values returned by old firmware.
How to read endurance metrics and the reality of drive lifespan
The real insight from this experiment is not the myth that "an old MLC SSD can survive 9PB of writes without dying." Rather, it's about what endurance metrics in storage actually mean, and the many different ways hardware can ultimately fail.
The TBW (Total Bytes Written) figure that manufacturers publish is not an absolute limit that predicts the exact moment hardware will physically fail. It's a benchmark figure grounded in a product warranty framework, guaranteeing that the drive can properly retain data under specified conditions.
In rigorous SSD endurance tests conducted in the past by outlets such as The Tech Report, straightforwardly repeating physical cell rewrites showed that various manufacturers' drives operated several to several dozen times beyond their rated TBW. But the SanDisk P4 case examined here is a different context from that kind of flash memory wear testing. It's a case that demonstrates the endurance limits of processing capability—specifically, how much I/O demand a controller can handle.
As the tester themselves points out, in real-world use, SSD failures are overwhelmingly more often caused by controller electronic component failures, firmware crashes, and mapping table corruption during power loss, rather than simple NAND flash rewrite exhaustion.
The simple controller used in this 2010-era test had an internal structure far less complex than today's highly sophisticated controllers. That very simplicity may be why it was able to keep processing—corrupting internal logs and throwing read errors along the way—without immediately becoming a completely unresponsive "brick." However, this result cannot be taken to mean that modern high-capacity SSDs using TLC or QLC would show similarly resilient controller behavior.
When judging storage lifespan, it's important not to be misled by surface-level write counter figures. When monitoring a drive's health, one needs to check the raw logs of reallocated sectors and uncorrectable errors—not just the overall "Good" icon. No matter how durable a product claims to be, it's a fundamental principle of storage operation to always account for the risk that it could suddenly stop responding without warning, and to maintain redundant backups accordingly.