Unless the information is made public by people who examine failures we wont really know, but from what I have researched, I think all of the following are possible causes.
1 - Early more primitive firmware having poor wear levelling so some cells fail way earlier than they would do with wear levelling.
2 - The address mapping table (sorry if I got name wrong), as I understand it is stuck on the same physical cells, certain workloads might wear these down before the other cells, I think also SATA ssd's with no DRAM would have accelerated wear on these cells as well. As I understand it NVME dramless ssd's can utilize system ram in place of a dram buffer so might not have this issue to the same degree although still riskier than onboard buffer.
3 - Bad firmware. Where a bug could brick an ssd.
4 - Blown capacitors or other failed circuitry, more likely on power cycles.
Enterprise SSD's because they have power loss protection, they dont honor synchronous writes, this reduces the window of vulnerability to kernel panics, as the data is written quicker, it also drastically reduces write amplification as synch writes are very bad for that. I actually emulate enteprise ssd behavior on my consumer ssd's when possible as I am now of the opinion it is safer. I have never blogged or posted about it before though as I am aware its a controversial opinion, but as an example, on a FIO sync write test, on one of my consumer ssd's in default mode it took 46s to write all data so 46s of vulnerability to kernel panic or power loss, with enterprise emulation (disabling sync on ssd but not the filesystem), the same data is written in 7s, so much smaller window of vulnerability. In this mode the filesystem still is sync not async, so isnt immediately reporting success to the software.
Full async it writes in 4s (with OS been told done immediately) providing there is no other writes at same time, as sync writes on filesystem nearly always take priority over async writes. So I still keep sync enabled on filesystems.
