Live data from Hacker News

SSDs: A gift and a curse

laur.ie

1–10 of 99 posts

Re: SSDs: A gift and a curse

#3
post #2

I am looking forward to the day when all SSDs ship minimal firmware, and offload all the complex work to (main-CPU) software.

Unfortunately that day isn't going to happen. In fact the opposite is happening -- interesting spinning rust technology like Shingled Magnetic Recording (SMR) drives are getting more complex translation layers.

Re: SSDs: A gift and a curse

#4
post #2

I am looking forward to the day when all SSDs ship minimal firmware, and offload all the complex work to (main-CPU) software.

SSDs that use SATA aren't going to allow any finer control, I suspect, due to the interface's limitations.

PCIe SSD devices, though, already feature an advanced controller (that is, a CPU core). This core could be programmed from the "computer" side somehow — but building any public API is always a major commitment, and takes much more effort than a proprietary API which you can change at will.

Re: SSDs: A gift and a curse

#5
post #3
post #2

I am looking forward to the day when all SSDs ship minimal firmware, and offload all the complex work to (main-CPU) software.

Unfortunately that day isn't going to happen. In fact the opposite is happening -- interesting spinning rust technology like Shingled Magnetic Recording (SMR) drives are getting more complex translation layers.

[deleted]

Re: SSDs: A gift and a curse

#8
post #2

I am looking forward to the day when all SSDs ship minimal firmware, and offload all the complex work to (main-CPU) software.

Having the flash translation layer on the drive itself is the only practical way for the drive to be usable by multiple operating systems. Almost everyone who uses a SSD wants it to be accessible to at least two operating systems (UEFI, and whatever OS resides on the SSD). Doing the FTL on the host system would basically relegate the SSD to being just a cache device.

Re: SSDs: A gift and a curse

#10
Of course SSD firmware is buggy. You know why? Because any half-decent electrical and computer engineering team can slap a NAND flash controller and some flash chips on a PCB, take the controller's manufacturer's reference firmware implementation, tweak the dozens of knobs provided by the reference implementation (ignore FLUSH commands, change the amount of reserved sectors, disable this, enable that, etc), change the device ID strings to "Company Foobar SSD 2000", and release the product on the market, with minimal QA and testing. And that's exactly what happened in the last 5-7 years with dozens and dozens of companies around the world designing SSDs.

But with traditional HDDs, the amount of engineering and domain-specific knowledge to manufacture and assemble the platters, moving heads, casing, etc, is such that there are only a handful of companies around the world who can do this (Seagate, WDC, Hitachi, etc). They have decades of experience doing that, so the firmware part of HDDs happen to be very robust as these companies have seen everything that can and will go wrong in an HDD.

So it boils down to this: which would you trust more, an HDD firmware code base that is 20 years old, or an SSD firmware code base that is 4 years old?

Combine this with the fact SSD firmware is much more complex (a flash translation layer must minimize write amplification, do wear leveling, spread writes on multiple chips, etc), and you are guaranteed that many SSDs on the market are going to be very buggy.

Post reply on HN