The SSD Review The Worlds Dedicated SSD Education and Review Resource | 
THE TRIM COMMAND
In newer operating systems, e.g., Windows 7, Windows Server 2008 R2, Linux 2.6.33, FreeBSD 8.2, Open Solaris, Mac OS X Lion, the TRIM command enables the OS to notify the SSD that old data is no longer valid about the time it deletes the logical block addresses from its logical table. The advantage of the TRIM command is that it enables the SSD’s GC to skip the invalid data rather than moving it, thus saving time not rewriting the invalid data. This results in a reduction of the number of erase cycles on the flash memory and enables higher performance during writes. The SSD doesn’t need to immediately delete or garbage collect these locations it just marks them as no longer valid.
The difference is illustrated in Figures 2 and 3.
Figure 2: Garbage collection without the TRIM command.
Figure 2 shows the process without the TRIM command in use. In column one of Figure 2, the SSD user writes four new files to the drive. The OS sees the files in its logical table, and the SSD has both a logical and physical view of the space available, which in the physical view includes over provisioning space that is not part of the drive’s stated’ capacity as known to the OS.
In column two, the user deletes file C, but the SSD does not know the file has been deleted because the TRIM command is not in use. If it does GC at this point, it will move the invalid data in file C because it doesn’t know it’s invalid. In column three, the user writes a new file E, the OS tells the SSD to use the same space it used from the old file C, and the SSD writes the new file to free space while marking the old space from file C as available for GC.
Figure 3: Garbage collection with the TRIM command.
Figure 3 shows the difference with the TRIM command. In this case, the process is the same when the user writes the four original files. When the user erases file C in column two, however, the old file C space is immediately marked as invalid in preparation for GC because the OS uses the TRIM command. The space originally holding file C is now free space to the SSD and becomes available as dynamic over provisioning meaning the SSD has more free space during GC which helps improve the overall SSD performance.
In column three when the user finally writes file E, the total free space on the SSD is now the same as the drive without TRIM. The difference is that the SSD with TRIM support knows what data is invalid and it can be considered free space during GC and prevents having to move the invalid data to another block.
This produces three key benefits:
- Lower write amplification. Less data is re-written and more free space is available during GC (more space to write equals fewer writes needed);
- Higher throughput. With the TRIM command, there is less data to move during GC and the drive runs faster. Throughput is bottlenecked at the flash an SSD is only as fast as it can write to the flash memory. During the time it is doing GC, the drive has to stop some of the data transfer from the host while it moves data around. This is why it’s beneficial for the SSD to know which data is invalid so it doesn’t have to be moved during GC.
- Improved endurance, because the drive is writing less to the flash by not rewriting invalid data.
Note: Today’s TRIM doesn’t work in most RAID environments because current RAID drivers generally don’t yet support it. Once more RAID manufacturers can make changes in their drivers, the hope is that TRIM will eventually work and benefit most RAID environments as well as non-RAID environments.
wow what a great resource, excellent work Kent, and thanks for contributing!
Can I say thank you 2 years after the fact? 🙂
Can I say thank you 6 years after the fact 🙂
Can I say thank you 8 years after the fact? 😐
Great article Les… I have added it to my running thread of “Useful SSD Articles” over at Tom’s Hardware (which included the other four SSD Primers).
https://www.tomshardware.com/forum/270102-32-useful-articles-part
.. That was useful. Thanks
While I agree that it is a good and informative article, let’s remember that this is written by someone who is biased and is not completely impartial. Kent works for LSI, which makes SandForce controllers, which are the controllers (the only controllers) that use DuraWrite technology.
He tells us how TRIM works in great detail, but offers next to nothing about when and how DuraWrite optimizes an SSD. This is probably because he cannot or will not let anyone in on the technical aspects of DuraWrite, his company’s proprietary technology.
I certainly would not want people to think that my TRIM explanation has any bias, so I will be as transparent as I can here. I think you do agree that the TRIM details here are pretty clear and I should reiterate that the explanation of its operation is orthogonal to DuraWrite data reduction technology.
If you want more information on DuraWrite, I do mention it in at least six of my blog posts https://blog.lsi.com/tag/durawrite/ and a few of them get into some details explaining how TRIM and DuraWrite will both help the performance of an SSD.
Les, I have an Intel 520/240GB and it frequently dumps about 20 x 1024KB “Intel_Trim_File” files in my SSD root directory. Do you know what these are and why they are there and SHOULD they be there? Thanks
I don’t know where these are and it is definitely odd. My suggestion is to hit our Forums and get the experts there to assist you with this!
i have a force sata3 120gb ssd.. i’m running windows 7…
in windows 8 setup there appears no recognition of my ssd so that it appears i cannot install windows 8 there… why is that… windows explorer sees it… i can write to it and delete files … why can’t i install windows 8 there…?
Les, very informative article, thanks.
“Step3: OS writes new file E to old location and SSD marks old LBA as GC and file E gets written elsewhere.” When the OS tries to read the file E, obviously the SSD returns data from this new location – but how does it keep track of this?
Also can you explain how overwriting a file works? Does the SSD do the same as step 3 and write the file elsewhere or does it move the block and rewrite it (essentially gc on the fly for that block?)
All NAND Flash-based SSDs have a flash translation layer that is a map showing all the locations known to the operating system and where in the flash pages they are mapped. This map is stored on the over provisioning space of the SSD and loaded into the controller when it needs to determine where data should be read or written.
This explains much more than I was aware of in the past. Bottom line though is about the same as I recalled from the past, a clean windows install is best. Migration will not perform the same and for a few reasons such as TRIM as one example. Another is disc defragmentation. A clean install does not install windows disc defrag while a migration or image will install windows defrag as the image came from a HDD. Best to start fresh and allow windows, windows 7 or 8 that is, to configure it’s system install for SSD applications.
I read an article not long ago that suggested Windows 7 and 8 doesn’t support trim. This was from an OCZ SSD review and it stated Microsoft confirmed this so, more elaboration on TRIM and what enables it is likely something that should be written.
Windows 7 and 8 fully support TRIM. If you post the link to the article that made you think otherwise we can review it and comment.
Since my research, I noticed OCZ is Chapter 11. No longer interested in them so Corsair will be the focus. I was unable to locate the articles I read as my history is gone after 90 days. I can say though, many of the SSD makers have these videos suggesting folks can take an existing HDD system and migrate/transfer that OS onto a new SSD. I read that may not survive or be the best solution for TRIM and many other things. Maybe that’s not accurate as well. We’ll see as my next build is in about 2 weeks.
Older OSes like XP used a different partition alignment than the more recent Windows 7 and 8. So if you migrate to Windows 7 or 8 I have not seen any problems with alignment any more.
If an OS is installed on an HDD, then it is defaulted to have TRIM off, but you can reconfigure the OS to turn TRIM on for that new drive once you get is set up. I will say that generally it is better to do a fresh install of the OS on an SSD, but I have personally used a transferred OS from HDD to the SSD and had no problems or issues. The benefit from the SSD is so much above the HDD it is hard to tell the difference from any other possible issue if something is not perfectly configured.
Let us know how your build goes.
The explanation for Fig. 1 is confusing. It needs to be stated that the saving a modified file effectively has OS telling the SSD that the Pages A-B in Block X are invalid.
I guess I am a bit confused because that exact statement is present below the center of the three images???
The caption says that Page A-D are invalid. The way it is written, there is really no difference between having TRIM or no TRIM. I assume this case is with no TRIM. In this case, when does the OS tell the SSD that data in Pages A-D are no longer valid? Basically, the same caption could be used to explain the case with TRIM.
The point that A-D being replaced by A’-D’ does not require TRIM is true for that case. That diagram is for the description of garbage collection, not TRIM. The operation of TRIM is covered in Figures 2 and 3. TRIM is required with the OS or user erase a file, but do not replace it directly. In other words, if I edit a file and save a new replacement over the old version, the OS will tell the SSD the new file should be kept instead of the old one.
In the case of a simple file delete, the OS or user have no direct replacement for that file, but just don’t need it any more. Without TRIM the file will appear valid to the SSD controller until the OS uses those same sectors or pages for a new file. Only then would the SSD controller know the old data is no longer required.
With TRIM the OS has a way to tell the SSD controller that the file locations can be freed up and no longer tracked during garbage collection.
the most right column in Figure 3 is misleading. the new file E is written, but the author moved the location of file D to the empty space and then put the file E in place of file D….this article has many areas that are not quite accurate.
I may have not understood it by I think the same on that drawing. I looked at it several times because I think it doesn’t fit completely the explanation.
Zappa, let me know if my answer to 48hours helps your understanding. If not I am happy to reply further.
Thank you, Kent.
My problem is with SSD Logical View and Physical View, but I just noticed I read this without reading page 1, so if after reading it I don’t get why I don’t see file C being moved both with and without TRIM, I’ll tell in case it’s useful for somebody.
5AM here :s
Thanks to Zappa, I was alerted to this question from 48hours that I missed when first posted. I believe the comment is about the “OS Logical View” at the top of the diagram. The physical order or layout of that view is irrelevant to the SSD controller and the explanation of where the data is getting stored.
As for the other comment that indicates there are other concerns for accuracy, I would love to hear them.
HI all,
I’ve posted the same questions on another forum but have not had any significant answers. It would be great to have your input on the following:
1 – OS is now MAC El Capitan but at the time was Yosemite
2- Hardware – Mccbook Pro (2011) 16GB RAM, 1TB Crucial M500 SSD (User fitted),
3 – Trim is NOT Enabled – I deleted a load of files back in May and have continued to heavily use my MBP since then for lots of Music, videos, documents etc. This includes lots of writing and deleting of files. It is used for around 8 – 12 hours a day and I hardly ever turn it off. I reached Max capacity at one point (not sure if I went into overprovisioning space), which slowed down the MBP and therefore moved a lot of files to an external hard drive which unfortunately no longer works
Questions:
1 – How soon after deletion would GC kick in without TRIM?
2 – Is there a sequence it works to. E.G. would it delete the older files I deleted before more recent files?
3 – Does it delete smaller files before larger files etc?
4 – How long would files stay waiting for deletion on a 1 TB SSD?
5- What is the likely hood of being able to restore previously deleted files, including ones from around May/June bearing in mind TRIM was not enabled and heavy use has occured since then?
6 – If I was to purchase programs such as ENCASE or others used by forensic analysists, would this help with restoring those files?
7 – When deleting files on an external HD (Non SSD) via trash can on my mac, does this give the possibility that I might be able to view a list of those previously deleted from the HD files on my internal SSD or would I need the external drive to be connected. E.g – Is there a trace left on the internal drive or files deleted on extrenal drives if they are not connected?
Thanks!
btrfs on Linux does support both RAID and TRIM.
Currently using 4 x Samsung 840 Pro 256GB in RAID 5 with 3ware 9750-8i.
Was impressively fast over a year ago when I set it up and now things get sluggish at random intervals.
Haven’t used more than 414GB of 712GB, system’s on 24/7 running Windows 8.
Buyer’s remorse starting to kick in… yeah, this late. All the while there’s no news on TRIM or alternatives on hardware RAID cards… Disappointing.
That raises a question to me.
Does Over-Provisioning unallocated space provide an advantage to formatted free space? I imagine it does because it is all unallocated so free to use, but formatted free space depends on the GC marks?
May E71 have not enough unallocated space for over-provisioning? (many say around 20-25%; if you need some of that space you can take it whenever you want).
And my most haunting question:
Does really TRIM function less efficiently if you shrink a partition to create unallocated space for Over-Provisioning? Some say it won’t ever work as well as installing Win 7 on a SSD with 20-25% of unallocated space.
Formatting or unformatted space has no affect on its operation as over-provisioning area. Free space is considered available to the user, so it cannot be part of the native over-provisioning. However, any unused user space that has been TRIM’d is available to the controller as what we call “dynamic over-provisioning.” More over-provisioning will improve any SSD controller.
In case something helps (you probably know much better than me but…):
– Could you notice SSD degradation taking a look at SMART indicators (with Samsung Magician, for example).
– Did you optimized everything? (except using RAPID tech, which may be trouble and probably is not worth it). Magician simplifies many passes of the optimization guide.
– Did you remember to reserve 20% of unallocated space for over-provisioning? I think the 840 comes with only 7Gb of “over-provisioning” space by default. Maybe the dynamic over-provisioning is not enough.
BTW, just slightly related, I read the 500Gb Samsung SSDs are faster when it comes to long data transfers because they have enough NANDs.
Thank you for that explanation. I feel better about putting the Cindori TRIM Enabler on my wife’s MacBook Air SSD upgraded to a Transcend JetDrive.
Wait, you upgraded your wife macbook with a flash drive ??!
No. SSD not flash. It was a 240GB JetDrive 500 SATA III Internal SSD model TRJD50024010. No problems with the upgrade or the part. Runs like new.
Oh, i was not aware that transcend uses jet branding for their apple ssds.
🙂
Thanks for the excellent primer on TRIM Les. If you wouldn’t mind providing input to the following question – it appears the SSD is responsible for translating logical to physical pages – lets assume I made a backup image of the SSD – on catastrophic SSD failure is my ability to restore using my backup image lost – or does the backup image include the SSD’s logical to physical translation?
HI all,
I’ve posted the same questions on another forum but have not had any significant answers. It would be great to have your input on the following:
1 – OS is now MAC El Capitan but at the time was Yosemite
2- Hardware – Mccbook Pro (2011) 16GB RAM, 1TB Crucial M500 SSD (User fitted),
3 – Trim is NOT Enabled – I deleted a load of files back in May and have continued to heavily use my MBP since then for lots of Music, videos, documents etc. This includes lots of writing and deleting of files. It is used for around 8 – 12 hours a day and I hardly ever turn it off. I reached Max capacity at one point (not sure if I went into overprovisioning space), which slowed down the MBP and therefore moved a lot of files to an external hard drive which unfortunately no longer works.
Questions:
1 – How soon after deletion would GC kick in without TRIM?
2 – Is there a sequence it works to. E.G. would it delete the older files I deleted before more recent files?
3 – Does it delete smaller files before larger files etc?
4 – How long would files stay waiting for deletion on a 1 TB SSD?
5- What is the likely hood of being able to restore previously deleted files, including ones from around May/June bearing in mind TRIM was not enabled and heavy use has occured since then?
6 – If I was to purchase programs such as ENCASE or others used by forensic analysists, would this help with restoring those files?
7 – When deleting files on an external HD (Non SSD) via trash can on my mac, does this give the possibility that I might be able to view a list of those previously deleted from the HD files on my internal SSD or would I need the external drive to be connected. E.g – Is there a trace left on the internal drive or files deleted on extrenal drives if they are not connected?
Thanks!
Thanks for your article! Great detail on the SSDs and how they work. I knew some of the detail but only a percentage. This article was much clearer at explaining why things move around so much. And thanks to LSI for letting you share your knowledge.
I have a question. Is there a way to tell when garbage collection is completed. So, if I Trim a file, it is ready for GC. But I don’t know how to know when it is really gone. The application in mind is more concerned with security than performance. Military and other applications of hard disks look to know the data can not be recovered by ne’er-do-wells. SSDs appear to out perform but how do we reassure people that GC is complete? Not sure if there is some command or API that tells us how much is left to be GC, or when the last full check of the SSD started/stopped. Any thoughts?
Thanks in advance and thanks for the articles!
There’s no way to know exactly when the GC calling executes unless you worked on the team that developed the firmware. I would assume military contractors could develop their own custom firmware but other than that someone who needs that kind of security should rather focus on encrypting such content-sensitive files directly.
Hey Ken. Sorry I missed your question. Locodoco is correct about the user not knowing when the GC process is complete for a particular portion of the SSD. Moreover, GC is performed at different times for some controllers. If the controller wants to optimize the life of the flash, it will perform GC as space is needed to prevent rewriting data which will be soon erased anyway.
In either situation, the GC and TRIM process is not necessarily enough for a military-level security environment. For situations where you must ensure the residual data is truly erased, you need to have a secure erase operation built into the FW. Not all drives support this capability.
Short of having a secure erase command built in, there are procedures where you can be fairly confident you have removed all prior data, but they would not meet any of the Mil Spec definitions.
The questions I have regarding all this is, how long in terms of time (minutes, hours, days, weeks, months etc) would it take for a Non Trim enabled SSD to get round to carrying out GC? Using the parameters of a 1TB Crucial M500 SSD which is used every day for various things including music and video editing? Would it be likely that GC could sit without occurring for months or is it more like the delay without TRIM would be hours/days?
Garbage collection is the same whether the drive supports TRIM or not, and it depends on how each drive manufacturer has programmed the GC calling to execute. So you should direct this question to Micron and/or the SSD controller manufacturer.
Locodoco is correct in that GC and TRIM are not dependent they way you have phrased the question. GC takes place based on when the controller is architected to manage the unused space. TRIM is sent by the operating system to enable the controller to know what previously saved data is no longer required and will not need to be saved during the GC process.
This is a very good article. You both covered technical detail as well as got them message out in layman’s terms.
Thank you sir! Spread the word.
Hi Ken. Thank you very much for the wonderful explanation. But I have some confusion that I hope you could clarify.
Q1: In Figure 2 (Row-4,Col-4), you mark C1 & C2 for GC and take away overprovisioning space. In Figure 3 (Row-4,Col-4) however, you again mark C1 & C2 for GC, but do not take space away from overprovisioning. They both look pictorially identical to me (except for the cell color of GC). Does this mean that at this point, the SSD knows the data is invalid in both cases? If yes, why isn’t it considering it as free space during GC in bith cases? Could you please better elaborate the difference between the two?
Q2: In Figure 2 (Row-4,Col-4), the overprovisioning space reduces and free space remains constant. Is it because in your example overprovisioning is assigned from available free space? If a dedicated portion of memory is set aside for overprovisioning, I would expect the free space to reduce, unless at this point SSD controller considers C1 & C2 as free space (because it already marked the blocks for GC). Could you please clarify?
Q3: If for Q1 above, the answer is that in Figure 2 (Row-4,Col-4), the SSD does not know C1 & C2 is invalid and therefore will re-write invalid data during GC, could you please elaborate at what time will the SSD know the data is invalid in a Non-TRIM architecture?
Q4: Lastly, just a clarification: I understand each cell in Figure 2 & Figure 3 (A1, A2 etc.) to be a Block and not a Page. Is that correct?
Hi. Thank you very much for the wonderful explanation. But I have some confusion that I hope you could clarify.
Q1: In Figure 2 (Row-4,Col-4), you mark C1 & C2 for GC and take away overprovisioning space. In Figure 3 (Row-4,Col-4) however, you again mark C1 & C2 for GC, but do not take space away from overprovisioning. They both look pictorially identical to me (except for the cell color of GC). Does this mean that at this point, the SSD knows the data is invalid in both cases? If yes, why isn’t it considering it as free space during GC in bith cases? Could you please better elaborate the difference between the two?
Q2: In Figure 2 (Row-4,Col-4), the overprovisioning space reduces and free space remains constant. Is it because in your example overprovisioning is assigned from available free space? If a dedicated portion of memory is set aside for overprovisioning, I would expect the free space to reduce, unless at this point SSD controller considers C1 & C2 as free space (because it already marked the blocks for GC). Could you please clarify?
Q3: If for Q1 above, the answer is that in Figure 2 (Row-4,Col-4), the SSD does not know C1 & C2 is invalid and therefore will re-write invalid data during GC, could you please elaborate at what time will the SSD know the data is invalid in a Non-TRIM architecture?
Q4: Lastly, just a clarification: I understand each cell in Figure 2 & Figure 3 (A1, A2 etc.) to be a Block and not a Page. Is that correct?
Hi. Thank you very much for the wonderful explanation. But I have some confusion that I hope you could clarify.
Q1: In Figure 2 (Row-4,Col-4), you mark C1 & C2 for GC and take away overprovisioning space. In Figure 3 (Row-4,Col-4) however, you again mark C1 & C2 for GC, but do not take space away from overprovisioning. They both look pictorially identical to me (except for the cell color of GC). Could you please better elaborate the difference between the two?
Q2: In Figure 2 (Row-4,Col-4), the overprovisioning space reduces and free space remains constant. Is it because in your example overprovisioning is assigned from available free space & not a dedicated memory for overprovisioning?
Q3: For a Non-TRIM architecture, at what point will the SSD know that the data is invalid and hence can be considered as Free Space?
Q4: Lastly, just a clarification: I understand each cell in Figure 2 & Figure 3 (A1, A2 etc.) to be a Block and not a Page. Is that correct?