SSDs, TRIM and performance drop offs in the real world
Posted by Vijay Swami on January 17, 2011
SSDs can dramatically increase the performance in personal computers.
Roughly 9months I installed a Crucial 128GB SSD into my Macbook (Model: CT128M225). It made an enormous difference with my user experience as I generally tend to run a lot of applications, VMs, etc on my laptop. The wait times for applications loading and disk I/O happening were reduced dramatically — no real surprise.
However, as time went on, I noticed that the performance, while still good, felt like it was dropping off. Since I performed some benchmarking when I first installed the SSD, it was easy to verify.
Summary table of I/O testing:
The data is from my normal HDD, my SSD when first installed, my SSD after ~9mo of use and filled up to 95% of it’s capacity, and my SSD after performing TRIM. The overall score is a weighted value that Xbench assigns based on the combined results, it is useful to get a rough idea of overall performance and based on that score, the last section details the performance gained & lost: the SSD improved the HDD performance by around 6.5x, and the SSD performance dropped over time by around 1.5x.
The reason for this performance drop off has to do with how data is read/written on an SSD drive compared to HDD. Rather than rehash all of that again, I’m going to quote a great article on the subject:
“NAND flash memory cells are grouped on pages and these pages make up blocks. Generally one page is 4 KB and a block 512 KB. It is possible to read or write Flash NAND by page, but you can only delete a block at a time.
Another parameter to take into account is that when a file is deleted by the system, the SSD is not aware of this as the operation is typically only flagged at the level of system files. The SSD is therefore only able to compute the invalidity of a piece of data on a page when you rewrite over it!
The resulting phenomenon is quite simple: when you write a new 4 KB file onto a page that has already been used, the SSD has to read the whole block, then delete it and then rewrite all the pages in the block. To write just 4 KB then, you might have to read as much as 512 KB, delete and write 512 KB, which obviously has a negative impact on performance, particularly in random writes of small files.
Another problem is how pages are addressed on Flash memory as the controller has to translate between the logical addresses used by the file system and the physical addresses of the corresponding flash pages. There is no fixed correspondance as with hard drives and the flash controller allocates pages as best as it can so as to optimise performance (write combining) and increase the lifetime of the cells (wear levelling).
Above all it’s aggressive write combining that can cause a problem. Write combining is a fairly simple technique that allows several writes to be combined and written in a single sequential burst: writing 32 pages at once onto the same block is much faster than writing 1 page onto 32 different blocks and also causes much less wear on the SSD. The allocation table then has to be updated so that LBA 0 = Page 0, LBA 133 = Page 1, LBA 289 = Page 2 and so on.
The only problem is that if you then have to rewrite such an allocation table sequentially onto the SSD, performance is severely reduced as it is not possible to use as many Flash memory chips at the same time as is necessary. Of course the SSD controller tries to reorganise the allocation table as best it can for this type of write but without any great success if all the pages have already been used once. Write combining is also undermined if there are no free pages as it can then no longer function due to a lack of raw space.
This is where the TRIM function comes in. First mooted in 2007 by T13, the technical committee in charge of defining ATA standard specs, it is a command that lets the system tell the storage device that an LBA contains data that is now invalid.
This may seem stupid but it will considerably simplify things for SSD controllers in terms of keeping performance levels up. In terms of the controller, there is no fixed implementation but logically speaking the reference in the LBA / Flash page allocation table is deleted.
Deleting each page physically at this time, in other words deleting the whole block to which it belongs and rewriting it again, would be completely counter productive from the point of view of the usure of memory chips, but sometimes a whole block that only contains pages no longer in the allocation table may be deleted.”
The drive I am using DOES support TRIM, however OSX (I use a MacBook) does not. This isn’t a problem for SSDs that Apple sells because they handle the issue via special firmware (non standard methods). Win7 for example does support TRIM, so theoretically it should not be an issue on that platform.
To solve this problem, I installed Ubuntu (Linux supports TRIM) and performed the TRIM operation via that OS. The downside is, it is destructive, but it’s not a big deal thanks to how easy it is to perform Time Machine backups and restores with OSX. Time Machine is really a killer feature of OSX IMHO. I followed the instructions on Jason Nash’s Blog to perform the TRIM operation.
So until OSX decides to support TRIM, it looks like this will have to be a 6mo or so periodic refresh for me.