Fragmentation over time and TRIM
This one took a bit to get my mind wrapped around. First a few pics. Here was this SSD when new:

HDTach run from when the drive was new. Read: 235 MB/sec | Write: 177 MB/sec.
And now here it is after our full test suite plus another 20 minutes of my SSD torture test routine (the one that could kill the unpatched Intel X25-M SSD’s):

HDTach run after a full round of benching and 20 minutes of fragmentation pounding.
Read: 232 MB/sec | Write: 164 MB/sec.
Read: 232 MB/sec | Write: 164 MB/sec.
Yes, you are reading that correctly. There was little to no impact. Even if I went from the fragmentation routine *directly* to the HDTach pass, the result would look as it did above. Even the mighty Vertex 2 Pro showed a little weakness after similar pounding. Sure this drive may not be as fast, but it’s proving itself to be very consistent in sequential access following heavy periods of random access.
TRIM
I don’t have and pretty charts or graphs to explain this next part, but I will share an observation I made during my fragmentation testing. When running my fragmentation tool, I observe IOPS drop as the drive becomes more and more overloaded with the task of tracking the random writes taking place. Here the JMicron controller behaved like all other drives, but where it differed is what happened after the test was stopped. While most other drives will stick at the lower IOPS value until either sequentially written, TRIMmed, or Secure Erased, the JMicron controller would take the soonest available idle time to quickly and aggressively perform internal garbage collection. I could stop my tool, give the drive a minute or so to catch its breath. Upon restarting the tool, this drive would start right back up at it’s pre-fragmented IOPS value.
Because of this super-fast IOPS restoring action, and along with the negligible drop in sequential transfer speeds from a ‘clean’ to ‘dirty’ drive, it was impossible to evaluate if this drive properly implemented ATA TRIM. Don’t take this as a bad thing, as any drive that can bring itself back to full speed without TRIM is fine by me, even if that ‘full speed performance’ is not the greatest.
This type of self-healing (i.e. without needing TRIM) is great for those wanting to run a few SSD’s behind a RAID, since no RAID implementation is currently capable of passing TRIM from the OS to the arrayed SSD’s. Better yet, considering this drive is tailored to the budget crowd who may very well still be running XP or Vista, it’s good to have a few choices that don’t require TRIM to maintain decent levels or performance.
I can’t help but think this background task might have been so aggressive it was getting in the way of normal operation of the drive, and might even be some of the cause for the poor IOPS performance seen throughout our testing. What should have been idle activity might have been taking while the drive was actually under read/write load from the OS.