Home  |  News  |  Reviews  | About Search :  HardWare.fr 



MiscellaneousStorageGraphics CardsMotherboardsProcessors
Advertise on BeHardware.com
Review index:
SSD, TRIM and IOMeter
by Marc Prieur
Published on June 22, 2010

Performance deterioration
We talked about this in our first article on SSDs, a used SSD doesn’t give the same level of performance as a “new” SSD; performance deteriorates with usage. Two phenomenons explain this. Let’s begin first of all with the usure that affects all SSDs when you write small blocks of data.

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.
Long live TRIM
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.


In any case knowing in advance which pages are available allows the controller to optimise writes, both sequential or random, and therefore avoid the problem faced when all cells have been used at least once.

In order to be able to use this feature, you need an SSD that supports it but also an operating system that can key into it. This is what Windows 7 does, as well as Linux and soon Mac OS X. In Windows XP and Vista, Intel and Indilinx are offering tools which read the file system allocation tables and tell the SSD via the TRIM command which LBA addresses aren’t being used.

<< Previous page
Introduction

Page index
1 | 2 | 3 | 4 | 5 | 6
Next page >>
Performance deterioration in practice  




Copyright © 1997- Hardware.fr SARL. All rights reserved.
Read our privacy guidelines.