The Crucial m4 SSD Update: Faster with FW0009

Testing TRIM

SSDs by default have no knowledge of what locations in NAND contain valid or invalid data. All writes are committed to NAND and it's not until an LBA is overwritten that the controller gets rid of the data previously at that address. Well designed controllers thrive with as much free space as possible, but without knowing what NAND blocks contain valid data the amount of free space on a drive from the controller's perspective diminishes over time. This results in the oh-so-familiar performance degradation over time that plagues all SSDs. The ATA TRIM command was introduced to help alleviate this issue. In a supported OS with TRIM enabled drivers, whenever data is deleted a command is sent to the SSD to TRIM the LBAs that map to the now invalid data. Upon receiving this command, modern SSDs mark those NAND blocks as invalid and schedule them for recycling. In the end this helps performance remain high over time.

Note that TRIM doesn't solve all fragmentation - you need a good controller with well architected firmware to ensure that fragmentation doesn't become an out of control problem. To understand how the m4's TRIM implementation performs let's first look at its fresh, out-of-box sequential write speed:

Note the relatively consistent write performance averaging 250MB/s. Now let's put the drive in a horribly fragmented state by first writing to all user addressable LBAs sequentially then performing a 4KB random write test at a queue depth of 32 across the entire drive for 20 minutes. This is what a sequential pass looks like after our little torture session:

Note the remarkable falloff in performance. Most of this is due to just how fast the m4 can write 4KB of data randomly across the drive, but it also shows that Crucial manages to reach such high 4KB random write speeds by not adequately combating fragmentation on the fly. Thankfully the drive does seem to recover pretty well, here's what it looks like after a second sequential pass:

Finally if we format the entire drive we get to see how well the m4 responds to the ATA TRIM command. To avoid giving the m4 an easier time I secure erased the drive, re-ran our torture test without the second pass (above) and then TRIMed its contents to produce the graph below:

Performance is back to new. What does all of this tell us? If you're running an OS with TRIM support you'll likely be just fine with the m4. Pseudo-random writes are common within any desktop workload, but if you avoid filling your drive to capacity and have a TRIM supported OS the drive shouldn't get into a bad state. The bigger concern is running the m4 in an OS without official TRIM support (e.g. Mac OS X) where you could find yourself in a particularly bad situation over a long period of time. Even then, it's obvious that sequential write passes over used LBAs cleans the drive up fairly well. Chances are that a standard desktop workload in a TRIM-free OS would be fine over the long run. If not, some sequential writes to any free space would do the trick (e.g. copying a large video file then deleting it).