The SSD Review The Worlds Dedicated SSD Education and Review Resource | 
DURAWRITE AND THE TRIM COMMAND
DuraWrite, found in LSI® SandForce® Flash Storage Processors, produces similar benefits to the TRIM command whether or not TRIM is present. And when TRIM is present, DuraWrite creates more free space on the SSD than would be possible otherwise. Figure 4 illustrates.
Figure 4: DuraWrite versus non-DuraWrite SSD Controllers and the TRIM command.
In a standard SSD without DuraWrite (row 1 left), data pending deletion and the free space share the same space. There is less space available for GC, so the drive has to spend more time doing GC to efficiently use the available space. In a conventional SSD that supports TRIM (row 1 right), the data pending deletion becomes free space, and there is much more space available for GC. The more space available, the faster the SSD can write, so TRIM has a big impact on the SSD’s overall performance.
In an SSD with DuraWrite technology (row 2 left), less data is physically written to the drive in the first place, so there is more free space available for GC. In fact, the amount of space available in a non-TRIM environment is comparable to the space available in a TRIM environment on a conventional SSD. Writing less data frees up more GC space and improves the performance of the SSD. In the DuraWrite drive with the TRIM command (row 2 right), there is a massive amount of space available for GC. However, having significant amounts of free space does not linearly improve the performance of the SSD, because there are other bottleneck points in place.
There are many techniques used in the storage industry, such as data de-duplication, data compression, and data differencing. DuraWrite combines elements of these and similar technologies in order to reduce the amount of writes that must be passed through to the flash.
Therefore, an SSD with DuraWrite in a system that doesn’t support TRIM behaves much like a regular SSD that does support TRIM. It is also possible to use DuraWrite in a RAID environment and get the benefits of having the TRIM command without the RAID drivers having to support TRIM.
BACKGROUND VS FOREGROUND GARBAGE COLLECTION
The final question is when to perform GC. There is debate in the industry between doing background (or idle-time) GC, and foreground (or standard) GC.
It seems like a good idea to do GC in the background, when the host isn’t demanding something of the SSD. It seems reasonable to perform housekeeping like GC when the SSD isn’t otherwise busy, so it can be ready with optimized blocks when the OS writes a new file or changes a file.
However, there are two problems with this. First, background GC can potentially relocate all of the currently valid data on the SSD, when in fact some of that data may be invalid e.g., in temporary files, or may otherwise soon be deleted by the OS. If blocks with invalid data are garbage collected in the background, the SSD will be rewriting a lot of data that won’t be needed in a short time, directly leading to unnecessary wear on the SSD and reduced endurance.
Background GC is used primarily with SSDs whose write speed is slow, because it reduces the amount of GC that must be done in the foreground, and therefore allows the SSD to perform a bit faster during writes. That is until the incoming host data traffic catches up with the freed space from the background GC at which time is it forced to perform it real-time.
Foreground GC, on the other hand, results in data being rewritten only when the free space will be immediately needed. Foreground GC thus avoids performing GC on data that will soon be invalid, and it reduces overall wear on the drive. This requires an SSD that has very high write speeds. LSI SandForce Flash Storage Processors have an architecture that enables the fastest possible foreground GC.
The difference between background and foreground GC is less obvious in consumer-level drives where there tends to be a lot of idle time and endurance isn’t as critical, but it is more obvious in enterprise-class drives, where writes occur all the time and duty cycles are longer.
LSI SandForce Flash Storage Processors use optimized GC techniques, so they can perform foreground (or real-time) GC better than the other SSD controllers. If the SSD also writes less data overall with the DuraWrite technology, there is less data to rewrite during GC, and the SSD performs even better.
As we have seen, GC is a necessary function of all SSDs. The decisions to use foreground or background GC as well as the use of the TRIM command impact an SSD’s performance, write amplification, and endurance. These factors should be carefully considered when designing SSDs or selecting one for a computer system.
In case this article has reached you through one of the many search engines, we should mention that this is the third in our series of SSD Primer articles meant to help us all along in our understand of solid state drives.
- BENEFITS OF A SOLID STATE DRIVE – AN SSD PRIMER
- SSD COMPONENTS AND MAKE UP – AN SSD PRIMER
- SSD TYPES AND FORM FACTORS – AN SSD PRIMER
- SSD ADVERTISED PERFORMANCE – AN SSD PRIMER
- SSD MIGRATION OR FRESH INSTALL – AN SSD PRIMER
- GC AND TRIM IN SSDS EXPLAINED – AN SSD PRIMER
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?