G.Skill Phoenix 100GB Solid State Drive Review

A Look at DuraWrite, RAISE and More

Let’s start with the white elephant in the room and explain why this 100GB drive is in reality a 128GB drive. The Vertex 2 has sixteen 8GB NAND chips onboard which gives it a capacity of 128GB, but is seen by the OS as 100GB. This is called “over-provisioning” and happens when a manufacturer has their drive consistently under report its size. Manufacturers use this to help increase IOPS performance and also extend life via wear leveling (as there is always free cells even when the drive is reported as “full”) and even durability since the drive has cells in reserve it can reassign sectors to as the “older” cells die. Having the Vertex 2 giving up 28GB of its capacity to this “buffer” is extreme to say the least when you compare it to the Vertex 120GB with its more typical 6.28% (8GB) set aside. Some (like OCZ, Corsair, etc.) have also released “extended” drives which sport firmware that basically does away with this over provisioning which in effect increases the overall usable space.


As we said, over-provisioning is usually for wear levelling and ITGC as it gives the controller extra cells to work with for not only keeping all the cells at about the same level of wear. However, this is actually not the main reason SandForce sets aside so much. Wear levelling is at best a secondary reason or even just a “bonus” as this over-provisioning is mainly for the Durawrite and RAISE technology. We will explain what those two technologies are but for the time being, let’s just say that while it there be “empty” space to some extent, it’s not really going to be 28GB of empty unused cells. Rather, this space is going to be used for other primary purposes.

Unlike other solid state drives which do not compress the data that is written to them, the SandForce controller does do real time loss-less compression. The upside to this is not only smaller lookup tables (and thus no need for off chip cache) but also means less writes will occur to the cells. Lowering how much data is written means that less cells have to be used to perform a given task and it should also result in longer life and even fewer controller cycles being taken up with internal house cleaning (via TRIM or ITGC).


Longevity may be a nice side effect but the real purpose of this compression is so the controller has to use fewer cells to store a given amount of data and thus has to read from fewer cells than any other drive out there (SandForce claims only .5x is written on average). The benefit to this is even at the NAND level storage itself is the bottleneck for any controller and no matter how fast the NAND is, the controller is faster. Cycles are wasted in waiting for data retrieval and if you can reduce the number of cycles wasted, the faster an SSD will be.

Compressing data and thus hopefully getting a nice little speed boost is all well and fine but as anyone who has ever lost data to corruption in a compressed file knows, reliability is much more important. Compressing data means that any potential loss to a bad or dying cell (or cells) will be magnified on these drives so SandForce needed to ensure that the data was kept as secure as possible. While all drives use ECC, to further ensure data protection SandForce implemented another layer of security.


Data protection is where RAISE (Redundant Array of Independent Silicon Elements) comes into the equation. All modern SSDs use various error correction concepts such as ECC because the simple fact of the matter is with any mass produced item there are going to be bad cells and even good cells are going to die off as time goes by; yet data cannot be lost or the end user’s experience will go from positive to negative. SandForce likes to compare RAISE to that of RAID 5, but unlike RAID 5 which uses a parity stripe, RAISE does not. SandForce does not explicitly say how it does what it does, but what they do say is on top of ECC, redundant data is striped across the array. However, since it is NOT parity data there is no added overheard incurred by calculating the parity stripe.


According to Sandforce’s documentation, not only individual bits or even pages of data can be recovered but entire BLOCKS of data can be as well. So if a cell dies or passes on bad data the controller can compensate, pass on GOOD data and then mark the cell as defective. As we said, SandForce does not get into the nitty-gritty details of how DuraWrite or RAISE works, but the fact that it CAN do all this means that it most likely is writing a hash table along with the data. This would explain on how it can not only assure data integrity but also why they have set aside so much of the storage capacity for these features.

SandForce is so sure of their controller abilities that they state that the chances of data corruption are not only lower than that of other manufactures’ drives, but actually approaches ZERO chance of data corruption. This is a very bold statement, but only time will tell if their estimates are correct. In the mean time, we are willing to give the benefit of the doubt and say that at the very least data corruption is as unlikely with a Vertex 2 as it is on any modern MLC drive.