White Paper: The TRIM Command
Posted 12/02/09 at 12:30:45 PM by Nathan Edwards
Though solid state drives have existed for years, it is only recently that they’ve gained any sort of market penetration for average users. As we stated in our February 2009 white paper on the subject, solid state drives offer many advantages over traditional magnetic drives. Unlike mechanical hard drives, SSDs have no moving parts, so they draw less power and produce no vibrations. They’re also more resistant to physical shock. And most importantly, solid state drives offer much higher read and write speeds than traditional hard drives—at least when they’re new. Due to their NAND flash architecture, SSDs can suffer serious slowdowns once they run out of fresh blocks to write to. The TRIM command, found in Windows 7 and newer releases of the Linux kernel, aims to fix this. But what is TRIM, and why is it even necessary?
When a file is deleted, the operating system doesn’t erase the data right away—instead, it marks that area on the disk as overwriteable in the index of all files on the disk, so the next time data needs to be written to the drive, it can use the space previously taken up by that file. This, incidentally, is why file recovery software works—provided the space hasn’t been written over, the data is still on your drive and can thus be recovered. It’s important to note that the drive itself doesn’t know anything about the status of the data on the drive. This blind-drive system works fine for mechanical hard drives since they can overwrite old data with no penalty, but because of the way NAND flash memory is arranged, slowdowns can occur once all the blocks on the drive have been used once.
The flash memory in solid state drives typically stores data in 4KB chunks, called pages, grouped in blocks of 128 pages each. Data can be read and written at the 4KB page level, but can only be erased at the 512KB block level. And while reading data and writing to unused pages on an SSD is much faster than on a standard hard drive, overwriting data is a complicated, multi-step procedure, one that SSDs typically perform only when they have run out of fresh blocks to write to.
When an SSD runs out of fresh blocks, it has to write over data the file system has marked as deleted. And that’s where the slowdowns begin. To overwrite a single 4KB page the file system first has to copy the entire 512KB block to its memory cache. Then, in cache, the overwriteable pages are deleted and replaced with the new data. Next, the entire 512KB block on the drive is erased and rewritten with the cached data. If you’re writing to many blocks at a time—either through a series of small random write operations, or simply by writing a large file to disk—you can overload your drive’s cache pretty quickly, and then your write speeds will plummet. You can imagine how slow it can be when you’re writing a 2GB file or performing lots of 4KB writes. Users of early SSDs sometimes found themselves with write latencies of up to a second. To compensate, SSD manufacturers began increasing the size of their drives’ DRAM cache to 64MB or even 128MB, and adopting faster drive controllers. This largely eliminated random-write stuttering, but drives were still slowing down as they ran out of fresh pages.
In a nutshell, the problem is that the OS and the file system don’t communicate information about deleted files to the SSD, and all writes to pages that contain unerased deleted data require a full block-level erase and rewrite, which can drastically reduce write speeds. There are two approaches to fixing this problem. The first is to run a garbage-collection program periodically that scans the entire drive and erases the contents of deleted pages. Many drive vendors now ship a program called wiper.exe that will erase deleted pages throughout the entire drive to return it to like-new performance. In some cases this program actually completely clears the drive, requiring valid data to be backed up beforehand. The second, better approach is to have the OS tell the drive when data is deleted, so that the drive can erase those blocks immediately. That’s what the TRIM command does.
When a file is deleted on a TRIM-enabled system, the OS sends a command to the SSD to let it know that the data in a particular set of pages can be overwritten, moving control over deleted data from the OS level to the drive’s firmware. The SSD then copies the blocks containing the deleted data to cache, erases the blocks, then rewrites only the pages with data on them. Thus, the caching and erasing process is moved out of the time-sensitive write cycle and into the time between the actual deletion and the next write, so the slowdown is less likely to cause a noticeable performance hit.
For the TRIM command to work, both the OS and the drive need to support it. TRIM is implemented in the Linux kernel as of revision 2.6.28, as well as in Windows 7, and all major SSD manufacturers have announced support. TRIM support may be added to some older drives via a firmware update, but not all older drives can support the TRIM command. If you plan on buying an SSD, make sure it supports the TRIM command—and if you already own an SSD, contact the vendor to see if a firmware upgrade is available. If not, your best bet is to see if your manufacturer has an SSD optimization utility (frequently called wiper.exe) that you can run on a regular basis to erase deleted pages.
I'll have to add this to the FAQ. Good thread.
If anyone is wondering how to tell if their TRIM-enabled SSD is actually performing TRIM commands, try this:
How Do I know if TRIM is working?
fsutil behavior query DisableDeleteNotify
DisableDeleteNotify = 0
fsutil behavior set DisableDeleteNotify = 0
awesome post, very helpful
glad to find out that my pc is already set for TRIM