Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
In the early days with hard disks, it was all fairly straightforward. The directory system used by the operating system (e.g. FAT, FAT32 or NTFS) kept a log of what files were held on the disk and where they were. When a file was deleted, to speed things up all the OS did was to remove the entry from the directory and effectively it was gone, even though the data remained on the disk. This didn't matter at all because this space was now free to be written on, even though it held old data. Whether it held 00000000000 or 012A62376F or whatever didn't matter at all, so why bother wiping the disk.

So here's the short answer:

With SSD's because they move data around in the background for optimisation purposes, the above mechanism no longer works. You need a way to tell the drive what data has been deleted, so it doesn't move junk around unnecessarily. That is what the Trim command does. It simply lets the drive know what data is no longer needed, so the SSD controller can deal with it appropriately.

The longer answer (if you are interested) is this:

[SNIPPED]

Chippy, thanks for the explanation. Your description of GC is very similar to something in my past, the GC done by Applesoft BASIC on the old Apple II's. It was something BASIC programmers hated, since it was done by the system and you had no control over WHEN it happened. So for no apparent reason, if the program had used enough memory that it needed cleaning up, your program would bog down until GC was finished.

So now the SSD makes more sense. I was viewing it as an HDD, not a memory space. Again, thanks for clearing that up. :cool:
 
Someone once told me, "never argue with an idiot, they will drag you down to their level and beat you with experience". Never a truer word.
Which is why I did not bother to explain it any further and I'm not going to change that.

Take a look at the presentation from Sandforce, "Garbage Collection - Understanding Foreground vs. Background GC and Other Related Elements". Hopefully you might learn something.
The only needing to learn something would be you. Had over to Anandtech like I told you before and read his articles. These are about ssd's in general and not specific to Sandforce. It is quite sad to see someone hang on to 1 little straw to "win" some discussion. If you really want to know what TRIM is you have to look at the ATA spec. Hdparm and the hdparm developer have very good documentation on this too.

"All SSDs will have some form of GC – it is not an optional feature"

"Trim makes more free space available during garbage collection"

If you wish, you could now go back and re-read my post and see that everything I said was 100% correct. Goodnight.
Yes because Sandforce doesn't sell anything like ssd controllers and thus has no benefit from stating something like the above... Just like the advertised speed which everybody will be able to reach without ease... Next time try to read through all the marketing propaganda and look at some real test data from independent testers. There are quite a lot of reviewsites out there that have a much better and more realistic look on these various drives and controllers. They tell a different store than the manufacturers do.

The document you linked to has some flaws. One of them is using GC as a very loose terminology where others have defined it much better. It seems that Sandforce defines GC anything that moves stuff around and clears cells. Ask yourself why they are saying things like "All SSDs will have some form of GC".

What it does not say is that TRIM heavily depends on quite a range of items: filesystem, kernel, drivers, ssd, SATA controller, ssd itself. The way FreeBSD does this is different from the way Linux or Windows does it.

All in all: TRIM and GC are different technologies that have the same objective. That's what it says if you read the technical papers of people who are implementing it instead of marketing talk from the company that sells the controller.

So here's the short answer:

With SSD's because they move data around in the background for optimisation purposes, the above mechanism no longer works. You need a way to tell the drive what data has been deleted, so it doesn't move junk around unnecessarily.
You are mixing things like TRIM/GC with wear-leveling here. It is not about moving junk around unnecessarily (that's what wear-leveling is for), it is about performance drops.

Simply put: you need TRIM/GC to regain a drive's speed because both an hdd and an ssd will drop in performance the more you fill it with data. To regain speed with an hdd you only needed to delete data but with an ssd this requires an extra step: it has to clear out the data from disk too. Which is exactly what TRIM/GC do: clear out memory cells that are allowed to be cleared out because they are no longer in use.
 
Which is why I did not bother to explain it any further and I'm not going to change that.

Oh the irony.

What the ******* is all the nonsense below about then? Lol

The only needing to learn something would be you. Had over to Anandtech like I told you before and read his articles. These are about ssd's in general and not specific to Sandforce. It is quite sad to see someone hang on to 1 little straw to "win" some discussion. If you really want to know what TRIM is you have to look at the ATA spec. Hdparm and the hdparm developer have very good documentation on this too.


Yes because Sandforce doesn't sell anything like ssd controllers and thus has no benefit from stating something like the above... Just like the advertised speed which everybody will be able to reach without ease... Next time try to read through all the marketing propaganda and look at some real test data from independent testers. There are quite a lot of reviewsites out there that have a much better and more realistic look on these various drives and controllers. They tell a different store than the manufacturers do.

The document you linked to has some flaws. One of them is using GC as a very loose terminology where others have defined it much better. It seems that Sandforce defines GC anything that moves stuff around and clears cells. Ask yourself why they are saying things like "All SSDs will have some form of GC".

What it does not say is that TRIM heavily depends on quite a range of items: filesystem, kernel, drivers, ssd, SATA controller, ssd itself. The way FreeBSD does this is different from the way Linux or Windows does it.

All in all: TRIM and GC are different technologies that have the same objective. That's what it says if you read the technical papers of people who are implementing it instead of marketing talk from the company that sells the controller.

You are mixing things like TRIM/GC with wear-leveling here. It is not about moving junk around unnecessarily (that's what wear-leveling is for), it is about performance drops.

Simply put: you need TRIM/GC to regain a drive's speed because both an hdd and an ssd will drop in performance the more you fill it with data. To regain speed with an hdd you only needed to delete data but with an ssd this requires an extra step: it has to clear out the data from disk too. Which is exactly what TRIM/GC do: clear out memory cells that are allowed to be cleared out because they are no longer in use.

I notice you have "form" in the argumentative troll department. I think i'll just leave you to argue on your own.
 
Last edited:
You don't need TRIM.
It made sense on old "slow" SSDs, but ones from within the last year are so fast that even low-end ones can saturate a SATA III interface. TRIM won't make any perceptible difference and I'd bet even benchmarks will have a hard time telling the difference between a used SSD that had TRIM and one that didn't.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.