> Software issues in SSDs were a problem in the early days -- I even had an early Intel 32GB SLC SSD that bricked itself even though it was nowhere near the end of its rated life.

They're still a problem. HP had two separate instances of branded SSDs fail when the lifetime counter rolled over (I guess they didn't test everything the first time).

My experience with running around 10k SSDs and spinning drives in a datacenter was that spinning drives would fail more often, but would provide clear warning signs if you check SMART stats regularly, providing opportunity to replace failing drives without losing redundancy if your storage systems are flexible. SSDs would fail significantly less often, but there would rarely be a warning --- disks would just disappear, never to be seen again. Our use was relatively low writes, we weren't anywhere near the lifetime write counts.

Some SSDs would really tank performance if they declared bad sectors, while they were moving things around, host driven I/O was very slow. I don't remember which brand that was.

If I were buying SSDs, HP is not at the top of my list of well known SSD vendors that have an excellent data integrity record, probably owing to an experience many years ago with HP branded MegaRAIDs that only had a known data corruptor in the HP "blessed" firmware.

My personal theory is that consumer gear tends to get better tested over the long run since millions of units out in the field will result in a lot of weird corner cases actually happening. The electrical engineers I know love it when their products are in high volume production, as it makes it a lot easier to find patterns and the underlying causes of failures. In contrast, low volume niche products will always have lurking bugs deep in obscure corners that haven't been exercised.

>Flash failures tend to be localized and directly related to wear caused by writes.

Flash doesn't fail when it wears out. SSDs simply become read only and get slower over time when they exhaust their write cycles. That's not a failure. A failure is something like your SSD controller bricking itself randomly during a power cut and instantly making all your data vanish.

That is a bit of a naive understanding of flash failure modes that is, unfortunately, incorrect. SSDs can lose data purely through read-only workloads. Flash suffers from read disturbances (just like the DRAM row hammer attack). Cells are not perfect, and electrical charge from adjacent rows/cells can leak. As a result, even idle data needs to be refreshed in SSDs. This is a case where there are major differences in the behaviour of NAND vs NOR flash, with NAND flash being more vulnerable.

There are also documented cases of Intel SSDs that should have gone read-only once reaching the end of their wear life failing outright due to firmware bugs. As is usually the case, software failures in corner cases abound.

You can choose SLC (or limited MLC) and overprovisioning to make flash storage quite reliable, and perhaps even preferable to disk in some respects. But that comes with severe compromises in density and you're still vulnerable to bugs in the opaque, proprietary Flash Translation Layer, which has no equivalent in (non-SMR) hard disks.

>Failure of flash is quite predictable and can be managed through the use of over provisioning and advanced error correction codes.

Do you have anything to back that up? because in real world even Intel server drives simply vanish from the system without prior warning, or promised read-only failure modes.

You are 100% correct that there is a gap between how firmware should behave versus how it actually does. Regardless, I still find the gradual wearout of an SSD to be preferable to experiencing an unpredictable head crash on a mechanical HDD.