Performance Over Time & TRIM

Testing TRIM functionality is important because it gives us insight into the drive's garbage collection algorithms. OCZ insists the Octane has idle time garbage collection, a remnant of the original Indilinx drives, however in my testing I could not get the idle GC to do anything once I put the drive into a highly fragmented state. Let's start at the beginning though. The easiest way to ensure real time garbage collection is working is to fill the drive with data and then write sequentially across the drive. All LBAs will have data in them and any additional writes will force the controller to allocate from the drive's pool of spare area. This path shouldn't have any bottlenecks in it; the process should be seamless. As we've already seen from our Iometer numbers, sequential write performance at low queue depths is around 280MB/s. A quick HD Tach pass of a completely full drive gives us the same result:

The Octane works as expected here, but now what happens if we subject the drive to a ton of 4KB random writes? Unfortunately this is where the Octane falls short. If we just throw a few minutes of random writes, constrained to a small LBA range, at the Octane its performance hardly varies:

However once the Octane passes a threshold of fragmentation, the performance drop is considerable. Our standard test involves a 20 minute, 4KB random write across all LBAs at a queue depth of 32. A sequential write pass across the drive afterwards took place at between 2 and 7MB/s. Since our test drive was a 512GB model, there simply wasn't enough time to conduct a full pass in the course of preparing this review. Instead I did a shorter test with HD Tach to give you some indication of what happens to the Octane under a highy random load without TRIM:

Performance drops considerably. A single TRIM pass restores performance to new. I did have one TRIM test where only the latter half of the drive seemed to TRIM but I couldn't get the same result more than once. Now the question is, what does all of this mean?

If you have TRIM enabled on a desktop platform with a client (read: non-server) workload, none of this should matter to you. TRIM works and there doesn't appear to be any weird lag or bottlenecks in the GC path. If you don't have TRIM enabled (read: OS X) with a client workload, this could warrant a pass. The only reason I'm hesitant to recommend the Octane for use with a TRIM-less OS X installation is because I'm not entirely sure the drive will recover from this ultra low performance state without TRIM. Sequential writing alone may not be enough to adequately restore the Octane's performance. Normally idle GC would be enough, but it seems as if things get slow enough the drive's idle GC can't do much. I suspect all of this is stuff that OCZ can tweak via firmware, but I need more time with the drive to really be certain.

Finally if you're deploying a server with lots of random writes, the Octane isn't for you. OCZ will eventually release an Everest based drive for the enterprise, but the Octane is not that drive.

ncG1vNJzZmivp6x7orrAp5utnZOde6S7zGiqoaenZIJygJZoq6GdXaSwu3nOnKuappViv6bCyJ6uZm1hZ7Sje5U%3D