OCZ Vector (256GB) Review

TRIM Functionality

Over time SSDs can get into a fairly fragmented state, with pages distributed randomly all over the LBA range. TRIM and the naturally sequential nature of much client IO can help clean this up by forcing blocks to be recycled and as a result become less fragmented. Leaving as much free space as possible on your drive helps keep performance high (20% is a good number to shoot for), but it's always good to see how bad things can get before the GC/TRIM routines have a chance to operate. As always I filled all user addressible LBAs with data, wrote enough random data to the drive to fill the spare area and then some, then ran a single HD Tach pass to visualize how slow things got:

As we showed in our enterprise results, Vector's steady state 4KB random write performance is around 33MB/s. The worst case sequential performance here is around 50MB/s, which is in line with what you'd expect. Sequential writes do improve performance, but as with most SSDs you're best operating the Vector with a bit of spare area left on the drive (in addition to what's already set aside by firmware).

TRIM and another sequential pass restore performance to normal, but it also triggers the Vector's performance mode penalty:

At 50% capacity there's an internal reorganization routine that's triggered on Vector, similar to what happens on the Vertex 4. During this time, all performance is impacted, which is why you see a sharp drop in performance just beore the 135GB mark. The re-org routine only takes a few minutes. I went back and measured sequential write performance after this test and came back with 380MB/s in Iometer. In other words, don't be startled by the graph above - it's expected behavior, it just looks bad as the drive doesn't get a chance to run its background operations in peace.