I've had an OCZ Agility 3 in my MM for about a year, and love it. However, OCZ (and possibly other vendors) are downplaying the need for TRIM to Mac owners because they know that Apple won't allow OS X to do TRIM for third-party drives. I know that's the official position of OCZ to Mac users, and it makes sense for them to say so because it helps sell drives.
I've been a computer geek for 25+ yrs, but SSD's are new tech, and I guess I'm a noob in this matter. I don't understand why GC or TRIM are even needed, since the volume directory and the volume bitmap should reveal what's currently used and what is unused. Why aren't these chunks lopped off when they are deleted? I don't understand why a separate process is needed to do this.
Can someone explain why it's needed?
EDIT: And before someone tells me to "use the google," I'm headed over to Wikipedia to try and find my own answer.
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:
Memory cells in an SSD don't have as long a life as sectors on a hard disk - they wear out. To get around this, SSD's employ a trick known as wear-leveling. This means that they spread the writing of data out over the disk so that the cells wear evenly. They do this transparently to the OS. The OS might thing it is reading and writing to the same place on the disk all the time, but in reality - in the background - the controller on the SSD is moving the data to different places so as not to wear out the same cells.
The second issue is that unlike hard disks, where the drive can write data to any part of the disk at any time, with SSD's you can only write to empty cells. So if a page of cells contains data already, that data has to be read in, then the page wiped and then rewritten again with the new and old data. But it gets worse. Although the SSD can write pages, erases have to be done on the whole block - 512Kb of data. Even though the new data you want to write might be quite small, you have to wipe the whole block and rewrite any existing data. Clearly this going to be much slower than if you just write to an empty page in the first place.
To get around these issues, all SSD drives employ some form of "Garbage Collection". That is, prior to new data being written (either just before, or a long time before) they spend time tidying up the data fragments into nice neat blocks, leaving as many pages as possible empty and ready for new data. Unfortunately, because this is all abstracted away from the OS, the OS cannot see what is in reality going on underneath. It (the OS) has one view of the drive - a logical view - and the SSD controller has underneath the full physical view of what is where and what can be written where. The OS doesn't know.
This is why it is impossible for the OS to do the physical tidying up of cells, pages and blocks - all it sees is its own logical view, not the reality underneath. The only place these optimisations can be done are on the disk itself by the disk controller. And to have a full view of what needs to be done, the disk controller also needs to be told by the OS what data has been deleted and need not be tidied up. That is what the Trim command is for. It is simply a command issued by the OS to the SSD controller to tell it what data has been deleted.
To be clear, the SSD controller can do its tidying up without the Trim command. If no Trim command is received, it just doesn't know what data has been deleted already. That may not matter too much if there are not many deletes going on and there's loads of free space.
But imagine you spend some time working on a powerpoint document, just by way of an example. As you edit it, PowerPoint is constantly doing background saves to disk, each time saving the latest version. Each time, the previous version is erased. This happens every few minutes. But it's not really erased, remember? Each time, the OS just updates the directory system and doesn't tell the disk controller.
Over the course of an hour or so on your PowerPoint document, you might save a 3MB document 20 times. There is now 60MB of data on the drive, 3MB of which is valid and 57MB of which is rubbish and which can be ignored. But the SSD doesn't know this. So it will spend its time trying to tidy up 60MB of data fragments, when it could be tidying up only 3MB, if only it knew.
Now imagine that happening with every file on your SSD drive. You can see that quite quickly there is a LOT of data on the drive that is in fact deleted and no longer required, but the SSD cannot know this unless the OS tells it. That is what the Trim command is for.
