Does anyone know whether Lion supports TRIM and if so, it does so as well for non-Apple SSDs?
I have a Crucial RealSSD C300 128GB SATA and I wondering how I can find out more about possible TRIM support.
OS X Lion-OTHER, Mac OS X (10.7)
If it has a controller (it does) and firmware with background garbage collection, the need for TRIM is over rated, especially if you leave ample free space.
Once SATA 3.1 spec is adopted, then TRIM will be part of the Native Command Queueing and handle function on the fly.
http://blog.macsales.com/11051-to-trim-or-not-to-trim-owc-has-the-answer
maigpl2 - thank you for the quick response.
Have you had any experience on SSDs with TRIM?
I am just wondering why Apple seems to be holding back on non-Apple SSDs and what the risk for enabling would be?
heck, SATA3 and SSD performance have been "MIA" so much, maybe they were waiting for SATA 3.1 and 3rd generation SSDs.
SSDs really only - for me - reached 'maturity' at the end of 2010, and now there is a lot of fuss over some of the newer models, firmware, and controllers.
BGC is what I would look for, not TRIM. A lot of PC users use RAID (Bios mode) and stripped SSDs, and TRIM is not supported on RAID.
And then, Lion won't install on RAID so that is another issue.
As for 3rd party TRIM driver support, I'd just buy OWC or one of the Sand Force based units.
No problems so far, using OCZ Vertex 2E 60GB.
Why they holding back on non-Apple SSDs its simple and its called Money! 😉
OCZ uses Sand Force, same as OWC (now) and Corsair.
I think it is more complex than people realize. TRIM Enabler took more work, and had some problems, and most of the PC users and what they have tried and gone through to restore write performance...? not for me.
As for Apple SSDs, those have had slow writes, slow performance, trouble in 2011 models. And SSD has been changing constantly for the last 3 yrs now.
Older SSDs needed TRIM. Companies face high cost per GB and trying to get customers to buy and embrace the technology.
OWC advises against using TRIM
To TRIM or not to TRIM (OWC has the answer)
as does Lifehacker
Your SSD already has built-in garbage collection. TRIM and garbage collection are similar, but they are not the same thing. Unfortunately, for some reason, the Apple driver for TRIM seems to conflict with drives that have garbage collection built-in to the controller, so you won't want to use it. It'll actually decrease your drive's performance.
OSX Lion does support TRIM but for only Apple branded SSD's, the reason as to why this is is quite unknown, Windows supports it, and so does Linux.
To give an example as to what TRIM does here is a video: http://www.youtube.com/watch?v=NnBk2IGYerU
So what is garbage collection on SSD's, basically SSD keep an area reserved, say 10-20GB for a 200GB SSD, this space is totally hidden from the user. So what the GC does is try to keep this reserved space free by analysing what is written and trying to reclaim blocks which might be empty, that is at the block level, not file system level.
The SSD controller only sees READ,WRITE command coming from the SATA interface, and it has no knowledge of the file system. The problem TRIM is trying to avoid is the read-erase-write cycle. This is caused because SSDs read 4KB, but write in 512KB blocks.
Problem is even with GC, you'll run out of reserve space if you keep your SSD full, and at some point the Controller will see every block marked as used, this where this read-erase-write problem comes (also known as Write Amplification).
So what exactly is TRIM, well TRIM is an OS command to the SSD, because the controller only talks in blocks and knows nothing of the filesystem, its like the OS is telling the controller that the OS has placed the following blocks as free.
This means the controller can explicitly ignore whats on the block and just marks it as free on its control set, so when you do a delete, the OS sends to the SSD controller a TRIM command telling it that the data is free.
A better description of TRIM can be found here: http://www.anandtech.com/show/2738/10
And unlike OWC you can read about the SF1200,SF2+ series drives OCZ Vertex 2 and 3, on windows not having TRIM enable means that the drive have a performance decrease (they benchmark it) even with GC.
So I dont know why Apple has it only enabled on their SSD's (which are slower). I have an SSD my self and to keep it healthy I have another margin of 20+ odd GB to keep the GC happy apart from Reserve Space.
Remember GC means nothing is the controller cant work out what blocks are free if they are all marked as such, SandForce drives have large reserves for this this is why they tolerate the degredation a lot more, eventually some blocks will be the same and the controller can keep them free, but like any SSD eventually they'll want an OS with TRIM enabled to free blocks to restore performance.
So I guess it must be the apple drivers which are broken, no surprise there >_>
2 myrddian - you're mixing reserved space with GC buffer - reserved space is much more than just what you told.
Exactly Sandforce GC works in special way - as they store say "virtual compressed image" instead of real data, that image is say "defragmented" all the time and thus all blocks "after the end of image" definitely are not used and can be cleaned by GC with same efficiency as trim, without knowing anything or filesystem structure.
2 hatter - all drives since '09 have GC, and trim does not conflict with GC. Specifically SF controllers have (not issues, but) slowdowns with trim, see:
https://discussions.apple.com/thread/2766683?answerId=15649687022#15649687022
And I'd strongly NOT recommend that SSD recondition.
I put a Vertex 3 SSD in my new 2011 MBP a few months back. I contacted OCZ support about using TRIM. They told me it wasn't necessary. They also told me to never "zero" a SSD drive when erasing/reformatting it.
FYI...Just for kicks, I tried that TRIM Enabler and experienced a bunch of 15-30 second freezes. I turned TRIM off and freezes quit.
No I am not mixing the two, all I am saying is that when all the blocks have been written to, the most the GC will collect aggressively is upto the reserve (or as the technical term Over-provisioned space). This is not backed by anything other than an aggressive discussion about it at work.
You really have to understand that an SSD does not behave in any way or form to a HDD, it reads in 4KB pages but writes in 512KB blocks. You also have to understand that an SSD has an utterly random mapping of LBA blocks to SSD Pages (which only makes sense to the controller).
To understand why this is so important you have to realise the limitations of the garbage collection system in that it can only "Free" blocks which it thinks have no data. You have to understand that there are multiple mechanisms in place in an SSD to even out the wear of the NAND cells in it.
Take for example a rather simple SSD with 4 Blocks:
Block A - Block B - Block C - Block D
When we write a file, it ends up on Block-A, now the wear algorithm kicks in, rather than writing to Block-A, it now writes to block B, if we update the file again, it ends up on Block C, we keep updating it up until it ends up where it started again.
So it goes like this: A->B->C->D->A
Garbage collection during write or Idle time, marks the blocks B,C,D as free rather than used, thats all GC does.
This gets more messed up when you realise that the SSD reports block sizes as 4KB, but remember we read 4KB write 512KB!
File system do not tell the SATA controller that blocks have become free instead they update meta-data information. The only thing the controller sees are READ and WRITE commands, thats all it sees, it cant work out if that data means its a deletion or modification and this is critically important.
So lets say that we have a file that chews up Three blocks!, A,B,C
We delete the file on our file system, we have to modify data block A (because thats where teh FS meta-data is), so the controller copies the A modifies it, and moves it to D, the garbage collector marks A free.
So to the controller, sees the following as used: B,C,D
The file system sees the following as used: A
So we have this extra data just sitting there, Garbage collector has no idea about the data in B or C.
This means any time we update a small section of this block lets say B, the data in B is read in, modified and written back out. This is why TRIM is needed, the file system says HEY block B and C are no longer needed.
Over-provisioning, so far our little SSD only has 4 Blocks, but hey lets say we had 20% hidden space that means there is one whole block sitting there "E" which the filesystem doesnt see.
Remember the file system sees the SSD as a series of sequential logical block addresses, but the controller remaps the LBA addresses to SSD pages which can be any where (this is why you can move data to another block while keeping the LBA address the same!)
So lets say We have all our four blocks full:
A,B,C,D (E is empty)
We modify data in Block A, but rather than copy the data back out to A, we instead write it to E, the GC then marks A free.
So Used: B,C,D,E
Free : A - Now is reserved
So why did I say the GC is more to do with the over-provisioned space, well it was because we (me and my co-workers) hypothised that the GC can only really aggressively mark free blocks that are duplicated on the provisioned space.
So now with over-provisioning and GC (but no TRIM)
If we delete a file that uses B and C blocks (again the FS might just flip a bit to mark a file as deleted, for this example I'll say its in the B block)
Before :
Used: B,C,D,E Free: A
After:
Used: C,D,E,A Free: B
This is what the SSD sees, so lets say you overwrite some of the data in C
The Controller cant tell where your files end and begin, because it only see READ, WRITE commands, it has no understanding of files.
So the controller will read all the data in C, and write to B, Freeing C
Now: D,E,A,B Free: C
So we have a disconnect as to what the File System sees as free and what the SSD sees as free, this is exactly what TRIM fixes.
It has been said in several respectable benchmarks, that TRIM keeps your SSD Happy, because the OS can tell the Controller directly whats free.
TRIM (http://en.wikipedia.org/wiki/TRIM) is also critical for keeping your SSD healthy, as it helps with the even-wear levelling.
All these, GC, and Compression try to reduce Write Amplification (http://en.wikipedia.org/wiki/Write_amplification)
This gets worse as more and more blocks on the SSD are used.
Now I bought a SandForce based SSD, because I knew they tolerated being run with out TRIM and after while only suffered at most a 25% penalty for it, it doesnt mean they are immune they will degrade and they will degrade faster with out.
On windows they can keep the performance up as if they were new with no problems, this is because of TRIM.
So yeah its not entirely necessary, if you want to shorten the life-span of the drive, and loose upto 25% of your performance.
Zeroing is never a good thing, because you wear out your writes, remember you only have a limited number of writes on your SSD (new MLC NANDs have about 6000 writes before they go pop), so if you Zero your whole drive you just wasted one whole write cycle.
And if you think I am crazy, please read http://www.anandtech.com/show/2738/10
http://www.anandtech.com/show/3681/oczs-vertex-2-special-sauce-sf1200-reviewed (yes its SF1200, but pretty much all of it applies to SF2 drives)
Any case, TRIM should not decrease the performance of your drive, my guess Apple has special timings on their SSD (because they have been benchmarked to be slower than other drives).
So I have no idea what Apple does on their TRIM implementation I did find this though : http://www.hardmac.com/news/2011/03/05/about-trim-on-mac-os-x
So it might be just a feature you get from only using Apple SSD's which is unfair especially for us consumers, given that its a standard SATA command, and should be supported on devices that support it.
So yeah I would be asking Apple to extend the support scope of TRIM, rather than just accepting it.
ok-ok, misread you.
if you're really interested in thing, I can tell you that there are at least Micron technotes in free access, on garbage collect and wear leveling and much more, on their site. And I did read (and understood) them.
Partially can tell you that "Over-provisioned space" is not some special area on die - just usual extra-space, used all the time by wear leveling and bad block mapping mechanisms. Furthermore, for GC to work it need really small buffer - as it works not in parallel - buffer for one block to defragment is enough. Maximum effective parallelism for GC - one operation for one memory channel - as memory bandwidth defines speed of GC anyway. Yes?
See, I took all that terms in "" - just to show that it not exact, but similar thing, to simplify understanding. I do know difference 😉
If you'll take in account wear leveling, you'll see that on die-level there are "absolute chaos" and in no way we can speak of "fragmentation" in terms of OS filesystem. But if we'll go one layer up - just higher than wear leveling address translation table - we easily can speek of fragmented/contiguous. still not OS level, but already fragmentation have sence. Got it?
And exactly on this layer SF controller do have CONTIGUOS say "compressed sparce image of drive" - and that image it internally mounts for you on newt level of abstraction.
Anything other than space, used by that image - is absolutely free - so can be easely cleaned. Contiguos state of image can be maintained absolutely without knowing it's internal format. Backside - trim lists correcponds to nothing physical as it intended to be - so trim is emulated. And as it is emulated, it is slow. Here we go with slowdowns on SF controllers with trim enabled. Nothing to do with quality of (Apple) drivers.
BTW there (was?) known problem with MS drivers cut length of trim sequences sent to drive, do you know?
Yes, I know over-provisioned space is not a special area, as you can tell from my example, its achieved by adding more MLC NAND to the board, SandForce drives have at least 25% of their drive capacity over-provisioned.
Actually SandForce controller have very little memory, as they do all their hard work on the NAND it self, which is another reason why they have more space on "reserve"
I am not speaking about the blocks as FS blocks they are SSD blocks as seen by the controller.
Your image metaphor falls appart, quite easily, as you use more and more space on the SSD this compressed image must expand because data can be random (giving little compression) or is already compressed, or just sheer entropy that the virtual volume has to expand. Now again the OS FILESYSTEM talks to the SATA controller using READ/WRITE commands, the SSD Controller only see READ/WRITE coming down to its interface.
So we get this right FS (LBA)-> SATA(LBA) -> SSD (LBA ->Virtual Image ->NAND blocks)
So before we continue lets gets these Axioms right
1. The File System see a LBA address range
2. The File System issues READ/WRITE commands to the controller in LBA blocks
3. The SSD translates this LBA address to a SSD Block map using its own internal tables
4. These Blocks relate to the MLC NAND locations
Now we will use your compressed image idea and add 2a. THE SSD Controller remaps LBA addresses to a virtual compressed image.
Let us clearly define the problem: the File system when erasing a file, changes meta-data in its own structures, and issues no ERASE (because it doesnt exists) to the controller.
I am assuming you need a crash course on File Systems too? Because you seem to have a hard time understanding that the SSD controller doesnt see files and doesnt understand what has been erased from the file system.
Imagine you have a File, the File System really is an Index think of it as a table
File Used Blocks
[ A ] -> 1,2,3
[ B ] -> 4,5,6
[ C ] -> 7.8.9
Free List: 10
This data is stored on the SSD it self occupying a block, when you DELETE a file what the FileSystem does, is really Move the Used block list for that file INTO THE FREE LIST.
Thats a WRITE command issued to the SSD.
Lets say you have this virtual image, the meta-data of the FS is stored on LBA address 1
this virtual image consists of 10 LBA addresses
So even if this compressed image existed, the controller still only sees a WRITE to LBA block 1, when in reality the FS is making free 3 sectors. the Garbage Collector will never see this as free, WHY? Because the WRITE contains no INFORMATION regarding what has been erased, UNLESS THE SSD CONTROLLER CAN READ NTFS/HFS/Insert Random FS meta-data, which we know IT CANT.
This Continuous Compressed Image in fact doesnt help at all in GC, because when the drive is used at Capacity the most the GC can collect is the over-provisioned space because that data is duplicated, at the start before all teh SSD NAND blocks are marked used the GC has an easier time, but once this has been writen over once, its down to the provisioned space.
SO JUST WHAT IS TRIM:
When the FS issues its WRITE, it sends a TRIM command, TRIM effectively amounts to an equivalent to ERASE, but rather its telling the SSD controller Block 1,2,3 arent USED ANY MORE you can mark them AS FREE.
Speaking of Quality of Apple drivers
Plenty of issues with the Quality of Apple drivers in relation to SSD's
I haven't heard of any issues with Window's implementation of TRIM, beta yeah, but not RTM/
OS's that Support TRIM on ANY SSD:
FreeBSD
Solaris
Linux
Windows
I mean come on, its no excuse really, I mean I can come up with more complaints about Hybernation not working on SSD's to many more, I've had more KOOPS on my MBP using the SSD, No excuse really, you can search this on google quite a lot.
So lets recap.
1. The file system makes tiny changes to erase a file, does this via a WRITE command
2. The SSD only sees LBA blocks, since to erase a file a WRITE with an LBA address is issued
3. The SSD still sees the space occupied by the file as USED because it hasn't been told its been erased
4. TRIM fixes this issue by notifying the SSD that the LBA blocks are now Free
5. With out TRIM the SSD has to do more work and will mean it will wear out your MLC NAND faster
Compression is great, it means that the SSD controller can squeeze more data and keep more blocks free to prevent failure, but it doesnt solve the issue of deallocated space on the media.
Let me make this clear, I am not saying that the other techniques dont work, but to say TRIM is not needed is plainly false, various manufacturers have stated that TRIM extends the life of your SSD by helping the controller keep more blocks free than otherwise it could pick up.
Apple definetly has TRIM enabled, for its SSD's , in the end if you want to ignore (extreme tech, Anandtech, TomsHardware, Intel, Crucial, etc) in regards to TRIM and its performance in favor of OWC please do so. What I am saying we should be asking for proper TRIM support from Apple to keep our hardware in good shape and performance.
I bought the SandForce controller based drives, because of its compression, over-provisioned space, garbage collection and its performance degredation charactaristics when TRIM is not enabled (yes it performs worse!: http://www.anandtech.com/show/3681/oczs-vertex-2-special-sauce-sf1200-reviewed/4) Its degradation is not bad 166(no-trim) vs 202(with-trim).
>So we get this right FS (LBA)-> SATA(LBA) -> SSD (LBA ->Virtual Image ->NAND blocks)
not exactly. we get this: FS (LBA)-> SATA(LBA) -> SSD (LBA ->"SPARCE" compressed Virtual Image ->wear leveling translation -> NAND blocks)
a sparse image file (.sparseimage) takes up only as much actual disk space as the data contained within - this is the key
most probably there are not one such image - but they definitely exists, as compressed data stream already is a partial case of sparce image. As we assume that controller writes compressed data to NAND (it does so, we know that) - it uses some-level compressed data stream(s), it's inevitable. And data in nand is some kind of archive(s). And one layer up - higher than wear leveling address translation - that archives easily can be contiguos.
And every OS-level block corresponds to something in archive. Not to block - as it is compressed, but to something, some part of unknown length and unknown address. So OS-level trim lists correspond to nothing on-die - and thus trim does not work as it should - mean does not really clean some list of NAND erase blocks, just mark some virtual blocks in translation table for sparce image as clean. But not really cleaning NAND blocks. Thus, not restoring drive performance.
You right about how trim works and what for it is intended - but look, I'm talking EXACTLY about SF2xxx controllers and PROBABLY other controllers which heavy internal compression - if there are any.
About shortening of sparce image without knowing content. As we have a list of LBA blocks that are in our image and we see that OS writes to one of that blocks again - it inevitably mean that content of that LBA block is no more. Thus, it goes marked to deletion purely on controller level, without knowlege of filesystem it holds.
And dont forget that most FS likes to reuse just-cleaned blocks on new writes in real life usage - so this simpliest-possible method would be effective enough. Until there are some free clean space for immediate write of what OS wanted to write. For example, in over-provisioned space
probably, only probably, that degradation you're talking of - 166 vs 202 - is due to overhead of maintaining stream (s) contiguous on-the-fly, I dont know.
actually you just have a target point shift in your logical structure.
erasing correct block is NOT the target point for maintaining drive.Target point IS - to have appropriate amount of clean spase for OS write request.
So, until we have some spare spase - deferred-until-next-write-over shrinking of virtual drive will perfectly fit
SATA-IO standard announced version 3.1 of SATA
The TRIM command specific to the SSD can now enter into the NCQ loop and thus be applied to the most relevant moment and not inevitably just with the erasing of the files and this should avoid a slow-down cat the time of erasing of large files.
Queued Trim Command - allows SATA SSDs to execute Trim without impacting normal operation, improving SSD performance
TRIM support for SSDs in Lion
