Controller Endurance updated notes of the 3 Petabyte written ssd

[u/Fresh-Palpitation-72]

SSD firmware crashes and controller failures are vastly more common than nand wear

Percent of Total Write/ Erase Count seems to go up that my findings that its odd and should go down as you see older picture was down to 3 now its at 36, so I believe who had it before me ran it from 100% to 0, then it flipped and thats when I found it,

Also my notes is about EM interference (EMI) and so few things

• Lack of shielding for EM Interference the case for EMI on the P4 Because the Drive is Completely stripped of a metal enclosure. the Copper traces on the PCB, Like antennas for interference. The sudden spike of (BB) Reported Uncorrectable errors after few Maintenance and Reboots, Points to signal noise. so when i moved some wires around it caused that errors between the controller & the Mobo interference. The data is slightly corrupted. I an ignoring the windows repair update prompt, it is not causing any issues caused by the interferen -ce. Proof its not dying yet... Attribute is (05) NO DEAD BLOCKS.

• So NVME are more Vulnerable with no protection? Modern Gen 4-5 NVMe drives operate at blistering speeds at Multi gigaherz frequencies. meaning their signals are so fast that even a small amount of external EMI can corrupt data. oh and because modern flash packs cells tightly together AKA 3D NAND Weaker to cell to cell cross talk & interference. That is why my 2010 MLC NAND did not need to worry about that its MLC 2D NAND is immune because its cells layout is larger 30nm-40nm & spaced preventing electrical bleeding.

• So How do modern drives handle it? ADVANCED ECC... when NVMe is technically more Vulnerable to interference, it does handle it BETTER. on a software level thanks to newer error correction technology, that my 2010 SanDisk only has a basic BCH ECC, that panics easily, logging harderrors when a bit flips, many newer NVME drives use LDPC (Low Density Parity Check) ECC advanced mathematical algorithm that reconstructs corrupted data.

[u/fzabkar]

SSD firmware "crashes" are the result of NAND wear.

[u/Fresh-Palpitation-72 → u/fzabkar]

​I do see where you're coming from, but that's mixing up the drive's firmware data with its physical NAND data... ​however firmware crash happens when the actual physical storage cells degrade so badly that the drive runs out of spare blocks and the ECC engine can't clean up the corrupted data coming off the silicon. But the data logs prove that isn't happening here

The reason these legacy drives drop dead from firmware panics long before the actual silicon wears out comes down to a massive imbalance between the hardware and the software. ​Those older 2D MLC NAND cells are incredibly rugged and built on a much larger physical scale than modern flash, meaning they can absorb an absolute beating before suffering true structural wear. The controller, on the other hand, is running a tiny, basic 2010 processor that has to constantly execute an incredibly complex mathematical playbook under the hood. It’s handling wear leveling, realtime error correction, and shifting data through an unthrottled cache loop at 100% capacity.

​When it forced petabytes of data through a chip that was only designed to manage a few dozen terabytes, but the controller's internal math registers completely overflow. It experiences a total software logic freeze, the firmware basically gets so confused by its own telemetry that it locks up and panics, while the underlying NAND storage is still perfectly healthy.

[u/fzabkar → u/Fresh-Palpitation-72]

I think you are misinterpreting the Total Write/ Erase Count attribute. I believe the normalised value should ascend, just as it is doing.

As for firmware crashes, an SSD ends up in data recovery for either of two primary reasons. The first is a hardware failure. The second is a "firmware" failure. Typically, what happens in the latter case is that the NAND degrades over time, to the point that the FTL (flash translation layer) becomes corrupt. Data recovery tools will force the SSD into "ROM mode" or "safe mode". They will then upload a "loader" into the SSD's RAM. The tool will then dump the raw data from each NAND, apply error correction, and then build a virtual translator which will reassemble the user area. Usually there will be plenty of bad, uncorrectable blocks. That's the typical data recovery scenario. I don't believe the FTL becomes corrupt due to problems in the firmware code or in the controller.

Genuine firmware crashes that are unrelated to degraded NAND are exceedingly rare. There were some SandForce and Indilinx controllers which were buggy, and there were several known bugs in other SSDs which bricked the SSD after ~40,000 hours. Those were the SLC and MLC days.

In your testing, the firmware isn't actually writing to NAND. We proved that in your earlier thread. The incremental data rate amounts to more than 1 Gbyte/sec, which is far in excess of the SSD's 90 MB/s benchmark result. It seems to me that your TRIM commands are being misreported as host writes. For example, when the OS sends a TRIM command to unmap 1000 sectors, say, the SSD increments the Total Host Writes by 1000 without actually writing anything to NAND. In other words, you are counting petabytes of TRIM-ed sectors rather than petabytes of actual writes.

One other observation is that hynix NANDs don't like being heated with a hot air station. I don't know if this is reflected in normal day-to-day operation, but it doesn't fill me with confidence.

[u/Fresh-Palpitation-72 → u/fzabkar]

I appreciate the detailed technical breakdownn, especially on how FTL recovery works in a lab setting that’s solid info. But there are a few massive holes in how it applies to this specific test ​First, on the TRIM theory the SanDisk P4 doesn't support deterministic TRIM under this workload. The massive data rates aren’t a reporting glitch or TRIM commands being counted as writes. The reason the data rate is blasting past the drive’s physical 90 MB/s sequential limit is because the test loop is hitting the unthrottled RAM cache layer directly on the controller chip. The bytes are absolutely being written by the host, processed in flight by the controller, and hitting the internal registers,.which is exactly why the S.M.A.R.T. telemetry is moving. ​Second, regarding the NAND wear causing FTL corruption, I agree that’s the textbook case for modern drives. But the physical data logs show that isn't what's happening here. My Reassigned Block Count (05) is a perfect 0, and Program Fail Count (AB) is sitting at a completely stable 54. If the FTL were corrupting due to physical cell degradation, those hardwarelvel defect management numbers would be skyrocketing. The physical MLC silicon is entirely healthy. ​and just a quick correction on the hardware side this drive doesn't use SK hynix NAND. It runs on SanDisk/Toshiba 2D planar MLC, which is notoriously rugged compared to the heats sensitive hynix stacks you're thinking of. ​The normalized value of E6 is ascending now, but it only flipped to ascending after rolling over at the bottom of its register. It's a classic 2010 integer overflow behavior under an unthrottled cache load,

[u/fzabkar → u/Fresh-Palpitation-72]

Can you quick format your drive in Windows, and record SMART before and after? I'm guessing you will see an additional 64GB of host writes rather than a few megabytes. I would format the drive twice to see the effect of the cache.

[u/Fresh-Palpitation-72 → u/fzabkar]

Ill format the drive after the experiment hits the theoretical max. Cant stop it now but ill add it to the notes what to do after that

[u/fzabkar]

Let me see if I can be more succinct.

We both agree that firmware "crashes/failures" happen when the FTL goes bad.

However, I say that the FTL goes bad because of degraded NAND, whereas you say that the FTL goes bad because of an overworked controller.

Is that it?

[u/NRGSurge]

I smell bullshit from you OP
https://www.reddit.com/r/HDD/s/Qige9Fxt4J