If Golem finds he has a performance increase after defragging, irrespective of the reason for it, I’d have thought that he and many others are going to defrag occassionally .

The fact that “fragmented files on an /ssd makes zero difference to performance”, in itself is really neither here nor there.

Maybe the defrag helped him by kick-starting his SSD garbage collection routine somehow, or maybe moving data away from a bad block of flash?

Fragmented files on an SSD makes zero difference to performance.

No you should not enable defrag on SSD, there is zero performance benefit and you are needlessly subjecting the drive to write cycles.

MLC flash is rated for 10’000 writes and SLC is rated for 100’000 writes so the “50 years of continuous read/writes” stat is only true on SLC drives, on MLC drives it’s 5 years.

However none of us will be continuously reading / writing our drives so the real-world longevity of an MLC drive is probably closer to the region of 20 years before we see any performance degradation or bad blocks.

If you play any high graphics online games (MMORPG types) you would notice a difference… More lag, more stutters…

I have seen it first hand… But if you are surfing the web and writing docs, you probably won’t notice…

If the real worry of SSD manufacturers is too much writing to the disk that occurs in a disk defrag session, then maybe the solution would be for a new type of defrag operation.

Instead of writing back and forth to the SSD device, the data on the SSD could be copied to a magnetic hard drive and defragged in the copy process. Then the data on the hard drive could be copied back to the SSD. That should lower the overall number of write operations that the SSD would accumulate.

Eg. Assume a volume that has, say, 10,000 files, perfectly contiguous/unfragmented with the free space perfectly consolidated. Now delete half of those files randomly. Voila! You have your free space fragmentation. Consolidating this free space needs only file movement, not file defragmentation,if you want to get technical:) The savings in erase/write cycles compared to defrag + free space consolidation would depend on the specific situation on the disk.

I found the original document that the previous link references by looking around the Diskeeper site.
http://downloads.diskeeper.com/pdf/HyperFast.pdf
They seem to have run the test on Apacer 8GB SSDs.

It doesn’t say anywhere that Hyperfast “itself does random writes”….so don’t know if I am missing something…

I also think that saying that they don’t need defrag, but need free space consolidation to be a bit of an oxymoron. Doesn’t defragmenting a drive consolidate (defragment) free space? Sure, if you’re not interested in reducing random reads you can defragment the free space without defragmenting the files.

Aside from disagreeing on Diskkeeper’s random read assessment, I find several other things suspect, not the least of which being that we’re looking at marketing presentations. Their tests are on an 8GB SSD? How old is this? The software claims to improve performance by reducing random writes, yet when the software itself does random writes it somehow performs higher?

It seems reminiscent of the ‘soft ram’ software marketed in the 90′s, which was generally software that provided a glorified page file. My guess is that HyperFast is some sort of software cache for SSDs, whether it actually caches read/writes or simply reorganizes the way the data is laid out before writing to disk (i.e. bundling 4k writes into 64k writes). I’m not claiming that it doesn’t work as advertised in practice, just that throwing a few marketing slides our way is fairly unconvincing.

Interestingly enough, defragmentation does still have a fairly profound effect on SSD performance, and I imagine it should still be done on occasion. Sequential reads can be up to 6x faster than random reads, and sequential writes can be faster by 20x or more (http://learnitwithme.com/?p=106). This may have to do with the way the flash controller manages the pool of flash, the controller seeing an attempt to write sequential blocks on the system side chooses a single location for that data, whereas random blocks may have to have several locations selected and remembered. Just a theory.