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



ProcessorsMotherboardsGraphics CardsMiscellaneousHard DisksSSD
Advertise on BeHardware.com
Review index:
SSD 2009, act 2: OCZ Vertex and Indilinx Barefoot
by Marc Prieur
Published on June 23, 2009

Deterioration in performance
We wrote about this in our previous article on SSDs; a new SSD generally gives better performance than a used one. Let’s begin first of all with the usure that affects all SSDs when you write small blocks of data.

The memory cells in Flash NAND ships 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 in the loop as the operation is situated at the level of system files. The SSD is therefore only able to know 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 writing 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 and as with hard drives, the Flash controller allocated the pages as best 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 pose 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 uses the SSD much less at the same time. 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 sequentially onto the SSD with such an allocation table, 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 considerable 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.

There are two conditions for the use of this function. First,the SSD has to support the functionality, whether when it is released or via new firmware as with the OCZ Vertex, and then the operating system has to be able to use it. Linux has this capability and Windows only in 7 and not yet for the beta versions.

Another solution is that OCZ offers a utility in beta version for 32 bit windows that allows it to use the TRIM function of the SSD. When the SSD launches the utility, it reads the file system allocations table and tells the SSD which LBA addresses are not being used via the TRIM command. And hey presto!

<< Previous page
Indilinx & OCZ Vertex

Page index
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10
Next page >>
Vertex usure in practice  




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