The Indilinx Barefoot 3 Controller

The OCZ Vector uses the Indilinx Barefoot 3, which is the first SSD controller that was developed after OCZ bought over Indilinx. Indilinx built upon their Barefoot 2 controller by adding the OCZ Aragon co-processor, which is a proprietary 32-bit processor with a SSD-specific RISC instruction set that OCZ claims would allow most SSD commands to be executed in a single clock cycle. Like previous Barefoot controllers, the Indilinx Barefoot does not use data compression to boost its performance.

OCZ has been very tight-lipped about the specifications of the Indilinx Barefoot 3 controller, but we know that the model used in the OCZ Vector is the first iteration - the IDX500M00-BC, which runs at 400 MHz. We also know that while the Barefoot 3 controller supports 256-bit AES encryption, this feature is disabled in the OCZ Vector.

The OCZ Vertex 450, on the other hand, uses the IDX500M10-BC controller with a slightly lower clock speed. Interestingly, 256-bit AES encryption is enabled.

Below are the specifications of the Indilinx Barefoot 3 (IDX500M00-BC) controller, as used in the OCZ Vector SSD :

The NAND Flash Memory

The 256 GB OCZ Vector solid state drive uses the IMFT M2502128TO48SX22, which is a 25 nm MLC (Multi-Level Cell) chip with a 16 GB storage capacity and an 8-bit data path. It is a synchronous part which is not only faster than asynchronous NAND flash parts but also runs at just 1.8 V, instead of 3.3 V.

There are 16 of these MLC NAND chips - 8 on both sides of the PCB, with a total storage capacity of 256 GB. As the OCZ Vector SSD has an official storage capacity of 256 GB, that means they did not over-provision the flash memory. Over-provisioning of NAND flash memory is important as it increases write IOPS performance by providing pre-erased blocks ready for use in the virtual pool of flash memory.

It also increases the perceived lifespan of the solid state drive by swapping bad blocks that develop over time with spare blocks. Over-provisioning of an SSD can take up as much as 20% as MLC flash memory don't have a very long lifespan. In fact, the lifespan of MLC flash memory gets worse as the lithographic process gets smaller. For example, each cell in this IMFT NAND flash memory chip is rated for only 5,000 program / erase cycles.

However, overprovisioning only becomes important when you are close to filling up the drive. If you have plenty of storage space left (10-20%) on the drive, it will behave no differently from an over-provisioned drive. You can also manually over-provision the drive by creating a smaller partition.

The SDRAM Cache

Unlike SandForce SSD controllers which use data compression to improve the SSD's performance and lifespan, the Indilinx Barefoot 3 controller uses a large SDRAM cache instead.

In the 256 GB OCZ Vector solid state drive, this comes in the form of two Micron 2DM77-D9PFJ chips - one on each side. These are low-powered DDR3L SDRAM chips that run at a 800 MHz clock rate (1.6 GHz DDR), with a capacity of 256 MB each.

The OCZ Vector's roomy 512 MB SDRAM cache not only caches the drive's reads and writes, but serves as a write-combine buffer. It accumulates and combines writes that are sent to the drive before actually writing them to the NAND flash. This improves performance by only writing full blocks of data, instead of fragments as they come in.

SSD Maintenance

First of all, you should never, ever defragment solid state drives using the usual hard disk drive defragmentation software. Spatial fragmentation of data has no effect on SSD performance - fragmented bits of data are accessed just as quickly as nicely packed blocks, so it is pointless to "defragment" the data blocks in the traditional sense. Doing so will also reduce the flash memory cells' lifespan by putting them under additional wear. This is important as MLC flash memory will only last about 5,000-10,000 program/erase cycles, and it will only get worse as the lithography process gets smaller.

Unlike hard disk drives, flash-based SSDs write and overwrite data in large blocks of 512 KB to 1 MB in size. Even if you only need to overwrite one byte of data, it has to erase and overwrite an entire block. This causes a lot of wear on the memory cells and greatly reduces their lifespan. To prevent that from happening, SSDs perform wear leveling by spreading the writes so that the flash memory cells have equal wear.

To further improve lifespan and performance, some SSDs use an SDRAM write buffer to temporarily store and combine writes before they are actually written to the flash memory. This reduces the number of block erases required and increases the memory cells' lifespan. This is how the Indilix Barefoot 3 controller improves the performance and lifespan of the SSD.

As helpful as wear leveling and the write combine buffer (or on-the-fly data compression) are, they cannot address the issue of "dirty" blocks, which will develop over time. Most operating systems will not directly inform the SSD which data blocks have been deleted. They will merely flag the deleted data blocks in their file system so they can be overwritten by new data.

Unlike the magnetic media in hard disk drives though, the NAND flash memory cells in solid state drives can only be written to if they are empty. Cells that contain data (even useless, deleted data) must be erased before any new data can be written to it. This requires the SSD to perform the time-consuming read-erase-modify-write cycle to overwrite the "dirty" block, which not only cripples performance but also increases wear on the affected memory cells.

To counter this, newer SSDs support the TRIM command, otherwise known as the ATA8-ACS-2 DATA SET MANAGEMENT command. Operating systems that support TRIM (e.g. Microsoft Windows 7) will notify the solid state drive when data blocks are deleted in the file system. This allows the solid state drive to perform garbage collection in the background - internally erase the affected blocks so that they are ready to be written to.

Like many modern SSDs, the OCZ Vector solid state drive supports TRIM. It also has an internal internal garbage collection feature which cleans up "dirty" blocks on a periodical basis, if it is ever used with an operating system that does not support TRIM.

Support Tech ARP!

If you like our work, you can help support out work by visiting our sponsors, participate in the Tech ARP Forums, or even donate to our fund. Any help you can render is greatly appreciated!