Although the Trim command has been defined for nearly a decade, for some reason I have never written a post to explain it. It’s time for that to change.
Trim is something that was never required for HDDs, so it was a new command that was defined once SSDs became prevalent. The command is required because of one of those awkward encumbrances that NAND users must accommodate: Erase before write.
NAND flash bits cannot be altered the same way as an HDD. In an HDD a bit that’s currently set to a “1” can be re-written to a “0” and vice versa. Writing a bit either way takes the same amount of time. In NAND flash a 1 can be written to a zero, but the opposite is not the case. Instead, the entire block (4-16k bytes) must be erased at once, after which all bits are set to a 1. Once that has been done then zeros can be written into that block to store data. An erase is an excruciatingly slow operation, taking up to a half second to perform. Writes are faster, but they’re still slow.
Let’s say that a program needs to Continue reading “What is an SSD Trim Command?”
The Storage Developer Conference in September gave a rare glimpse into two very different directions that SSD architectures are pursuing. While some of the conference’s presentations touted SSDs with increasing processing power (Eideticom, NGD, Samsung, and ScaleFlux) other presentations advocated moving processing power out of the SSD and into the host server (Alibaba, CNEX, and Western Digital).
Why would either of these make sense?
A standard SSD has a very high internal bandwidth that encounters a bottleneck as data is forced through a narrower interface. It’s easy to see that an SSD with 20+ NAND chips, each with an 8-bit interface, could access all 160 bits simultaneously. Since there’s already a processor inside the SSD, why not open it to external programming so that it can perform certain tasks within the SSD itself and harness all of that bandwidth?
Example tasks would include Continue reading “SSDs Need Controllers with More, NO! Less Power”
One of the thorniest issues in SSD design how to manage erasing blocks that are no longer in use. That’s saying a lot, because NAND flash presents so very many difficult challenges like wear leveling, bad block management, error correction, and write amplification.
The difficulty stems from the fact that all of today’s software was written for HDDs which don’t behave like the flash in an SSD. An HDD can over-write existing data with new data. In a flash SSD, a block must be erased before being over-written and this can take a half a second – a huge amount of time in the world of computing. Since the software doesn’t accommodate flash’s “erase-before-write” needs, the controller inside the SSD must take care of this bit of housekeeping. Unused and unerased blocks are moved out of the way and erased in the background. This is called the “garbage collection” process. Continue reading “SSD Garbage Collection”