TRIM vs. Garbage Collection: Beating a dead horse

[WyomingKnott]

With his permission, I am going to re-post a private conversation with Tecmo34. The subject is, once again, whether Garbage Collection can replace TRIM, or if they are complementary.

Despite the massive number of posts on GC being sufficient, everything I have read about GC indicates that it collects used pages into entire used blocks, thus making more space available for immediate writing and reducing write amplification. But when a file is deleted, the pages of the file are not touched; it's done with the directory entry in the filesystem. So unless the SSD can read the filesystem or allocation tables, I can't believe that GC can replace TRIM.

WyomingKnott:
A side question on SSD cleaning. For garbage collection to work, wouldn't the drive have to be able to read the allocation information or directory information that is part of the filesystem? The blocks themselves don't have allocation flags on each block; all 4K is available for data.

This came up from a discussion with a colleague who is using an SSD in Vista for his data only - he does video editing, and data reads and writes are his limiting factor.

Thanks in advance
-Peter (WyomingKnott)

Tecmo34:
Peter,

Here is a few things you can read through to get a better understanding... 1) is from Wikipedia & 2) a thread from Tom's... [<user xxxxx> is one of the most knowledgeable users for SSD's (he is a beta tester of OCZ & works with their tech group & is very respected in their forum)]



http://en.wikipedia.org/wiki/Garba [...] collection
http://www.tomshardware.com/forum/ [...] ative-trim


The key with GC is idle time... It works just as well as TRIM does just at a slower pace. You have to remember TRIM is just a command to speed up the identification process and GC does all the work.

If you have any other questions, feel free to ask any time

Best Regards,

Doug

WyomingKnott:

/*** Begin embedded quote
tecmo34 wrote :

Peter

Here is a few things you can read through to get a better understanding... 1) is from Wikipedia & 2) a thread from Tom's... [<User xxxx> is one of the most knowledgeable users for SSD's (he is a beta tester of OCZ & works with their tech group & is very respected in their forum)]
<snip>
The key with GC is idle time... It works just as well as TRIM does just at a slower pace. You have to remember TRIM is just a command to speed up the identification process and GC does all the work.

If you have any other questions, feel free to ask any time
Best Regards,

Doug
/*** End embedded quote

Me again. The Wikipedia article seems to confirm my original suspicion (but I am aware that a person will read 20 reports and find the one thing that supports hist point of view).

/*** Begin embedded quote

If the user or operating system erases a file (not just remove parts of it), the file will typically be marked for deletion, but the actual contents on the disk are never actually erased. Because of this, the SSD does not know the LBAs that the file previously occupied can be erased, so the SSD will keep garbage collecting them.

/*** End embedded quote

So overwritten blocks are easily Garbage Collected. If I had a pre-allocated database on an SSD, I'd be writing to the same allocated space over and over and GC would see the overwritten pages.

But if I'm Joe User, which I am, and I'm doing cleanup by deleting files that I no longer need, without the TRIM command the SSD has no way of knowing that those pages are no longer used and will continue to protect them, and even copy them as part of the GC process.

Groberts101 wrote

/*** Begin embedded quote

TRIm(not available in raided volumes) and SE is not needed since I can and often do write many times the capacity of my drives without ever seeing read/write/modify speed degradation effects. Have to avoid doing that all in one session though and implement idle time recovery/GC in between logins to recover dirty blocks for the next sessions workflow.

/*** End embedded quote

But he didn't describe any way that the SSD could be GC'ing deleted files. So I am still, despite my usually open mind, hoping to get

Wikipedia also writes that

/*** Begin embedded quote

SSD Manufacturers that did not originally build TRIM support into their drives can either offer a firmware upgrade to the user, or provide a separate utility that extracts the information on the invalid data from the OS and separately TRIMs the SSD. The benefit would only be realized after each run of that utility by the user. The user could set up that utility to run periodically in the background as an automatically scheduled task.

/*** End embedded quote

Despite the fact that I can do a Google search myself, I haven't found such an object. Do you know of one, and if they are vendor-specific or will work with any SSD?

And then later: Ignore my dumb question about a utility. I managed to read the thread without AS Cleaner registering. It registered when I re-read the thread.

If you managed to read through all of that.... So I have two conflicting pieces of information. First, experienced users say that GC is sufficient. Second, I have seen no explanation of a mechanism other than TRIM by which the SSD can tell that these 5,000 pages are now free space after a file is deleted.

If anyone knows how GC can accomplish this, I would greatly appreciate an explanation. If anyone knows for sure that the two are complementary and GC cannot make free blocks from files that were deleted, I would greatly appreciate that.

If there is a way to get an SSD to tell you how much space it thinks is used, I could do an easy test. Put the SSD on an XP system, in IDE mode. Write a bunch of files to it, and look at how much used space the SSD thinks it has and Windows Disk Manager thinks it has. Delete the files, and again check both measures of used space - they should disagree by the amount deleted (if they agree, did TRIM happen?). Then let the drive sit overnight to run GC. Finally, check the two measures of space used. If the SSD and Disk Manager agree, it saw that the space was deleted. If the SSD still thinks that the space is used, then TRIM is still necessary in addition to GC.

This inquiring mind really wants to know.

 

[JohnnyLucky]

The truth is out there!


SSD garbage collection was developed before Microsoft Windows TRIM.

There are different types or methods of garbage collection. Some types are very aggressive like those designed for systems with no Windows TRIM support. They actually do work quite well. Other types work best when the pc is idle. They work well in conjunction with Windows TRIM. Think of it as a delay until conditions are more favorable.

If memory serves, Anand over at AnandTech has written quite a bit about TRIM and different types of garbage collection. Sometimes he'll go into detail during an ssd review.

 

[groberts101]

That horse is quite smelly by now.

All that needs to be remembered here is that all modern SSD controllers simply compare data mapping between logical and phyical states of the filesystem using their internal smarts.

Can TRIM still help?.. well sure it can as the controller can use that updated information in real time. Whereas GC requires more low activity idle times to allow the controller time to compare and make necessary adjustments without being rushed. With some controllers out there(Sandforce in particular).. it's actually better to have both as the TRIM commands will make the controller more efficeint at wear leveling due to immediate notification of what's best to clean for on-the-fly recovery.. and then to allow the drives greater reaching benefits of GC to go even further such as static data rotation and partial block consolidation.

I've had older Indilinx drives in raid for years now and they simply do not slow down until you write to all free blocks available in a single logged on session. But then an overnight logoff is added and they are back to fresh speeds once more.

Furthermore.. I have been beta-testing a newer Everest controlled SSD called the Octane for OCZ and the drive will not even slow down nearly at all even running off a raidcard and/or with TRIM completely disabled altogether. In this case the on-the-fly recovery is done in real time and TRIMLESS environments do not cause it to suffer one little bit. And trust me here when I say.. I've made this drive suffer by filling it nearly full and running 9 x 4000MB CDM3 tests over and over again to find weaknesses. Only time is starts to slow down in any measurable way.. is when the drive hits more than 90% full with huge amounts of data being written to it.

So, no.. TRIM is definately not required for the controller to figure out what has been deleted at the filesystem level. TRIM is just one means to the same end result and lets the controller operate more efficiently to update its current data map. Simple as that.

 

[WyomingKnott]

That horse is quite smelly by now.

So, no.. TRIM is definately not required for the controller to figure out what has been deleted at the filesystem level. TRIM is just one means to the same end result and lets the controller operate more efficiently to update its current data map. Simple as that.

The reason that I can't leave the horse to rest in peace is - how does the SSD firmware know? Does it understand the filesystem or allocation tables? Does it know NTFS and read the directory structure? Without something like that, there doesn't seem to be any way for the drive to figure out which once-used blocks are no longer used. Since you have seen it clean up properly, I have to believe it, but HOW IS IT POSSIBLE??

 

[groberts101]

Don't quote me here.. but from what I've been told(or remember anyways).. the drives keep real time internal mapping comparisons of the curent and ever changing LBA/metadata structure of the logical data bitmap. So, in this effect it matters not whether it's an SSD used for a storage only volume.. or one in which the OS resides as the data map is still compared.

By deleting data at that LBA and changing metadata?.. the drive remaps accordingly so that the newly deleted data is no longer seen as viable data by the SSD controller. As any HDD would do.. the flash actually still contains the necessary bits and pices of that data UNTIL the controller wipes the map and recovers that space to be overwritten again without read/write/modify.

It's been said that some controllers need to first clear that data to make way for the next bits to be written(to actually avoid read/write/modify penalties).. whereas some others are simply letting the new data be written freely without penalty due to the maps being modified in real time and simply reallocating them to be used immediately and without penalty. Dunno.. but I imagine these things are smart enough by now to do it any way the coders are able to work within the constraints of that particular controllers inner restrictions.

So in essence here, the controllers mapping is constantly updated to reflect what is viable data at the logical level. When the controller then compares that current internal map with the newest map from the now changed logical bitmap?.. it see's that data has changed and those once occupied blocks are free to recover.

BUT.. not all controllers will recover them in the same fashion, as efficiently, or even right away(as in Sandforce's lazy deferred recovery). Overly aggressive GC can and does increase WA on SSD and a happy balance is constantly being held to avoid wearing out individual cells.

This is where controllers are constantly evolving and making improvements in how they are able to process the differences between these internal maps and to subsequently allow the once used blocks to be recovered.. and in what order which is where TRIM can reduce WA quite substantially on some controllers. Some need low activity idle time to make the best of those algorithms, whereas some do it realtime without much slowdown being perceived by the end user.

IMO, the various controllers will tend to leverage incresed amounts of DRAM onboard for that very purpose and to aid on-the-fly recovery processes. In fact.. look how far we've come already in such a short time. DRAM is starting to reach 512MB's already and next gens may even start to see 1 gig.

However they choose to do it internally?.. they are obviously getting better and quite capable of doing it without TRIM being needed to notify the controller that data has changed and can now be deleted/freed at the maps level follwed by the release of those blocks back into the fresh pool to be written to without penalty.

Kinda wordy and a bit babbly I know.. but I'm trying to multitask right now and that's about the best I got for ya at this moment without getting carpal tunnel or shutting down my other apps and.. 11 browser tabs. lol

 

[JohnnyLucky]

It's Magic!

Seriously though, the SSD controller keeps a bitmap of blocks

 

[abeeceedee2001]

You are missing the point. If I delete a file in windows, the SSD has no way of knowing if that file has been deleted or not. Windows simply removes the pointer to the file, but the data is *not* erased. The SSD does not contact the Windows file system to determine if data is part of a valid file or not.

Trim will eventually tell the SSD to delete the file. BUT, if the SSDs are on a raid controller, the trim commands do not get passed through the raid controller.

Until windows says to overwrite the LBA of that data, that the SSD will know to put data there.

Thus the LBA for that deleted files will continually (and unnecessarily) be GCd by the SSD.

 

[WyomingKnott]

Ehh, the people who disagree do get that point, they just don't agree with it. I have found technical documents arguing both ways. My personal belief is based on what "makes sense" to me after reading various docs, but lots of real things don't make sense to me.

I recently read a tech article that agrees with you - see the example "Garbage collection without the TRIM command." http://thessdreview.com/latest-buzz/garbage-collection-and-trim-in-ssds-explained-an-ssd-primer/2/
However, even if that's correct, perhaps Windows is grabbing the deleted blocks for new files fairly quickly, so it doesn't make much of a diff. I have seen many articles that state just the opposite, that GC can do what TRIM does, but it takes longer.

And that poor horse had been resting since the end of January. Dug him up again, we did.

 

[abeeceedee2001]

LMFAO - yes we did! I can tell you with 100% certainty that GC does move deleted file data around until the Windows OS actually trims the clusters, or overwrites them with new data in which event GC will still move those same pages around, unless the entire block is full. Its a conundrum!

My heartburn right now is with SSDs and LSI Cachecade or EMC VFCache, how do they handle this?

 

[psaus]

I don't have hard documentation on this, but my logic is this:
When a file is deleted (as in PURGED from the recycle bin), the OS breaks the pointers to the address blocks (as has always happened on HDDs). For SSDs the OS only sees a logical table of addresses and manipulates this. An SSD must interpret and maintain the Logical to Physical conversion tables already (wearleveling), so when the SSD sees the pointer removed, it tags the physical table location for idle GC.

@WyominKnott, a better test compared to the one you outlined in your OP would be:
-= W7 w TRIM vs XP (wo TRIM) (or a W7 with TRIM disabled in the registry) =-
A
- Using a drive that has been secure erased to start
- use a script that fills the drive
- as soon as the drive fills execute a delete command
- immediately start writing again til full.
- compare the time differences between 1st and 2nd pass as well as the diffrence between the 2 OSes

B
- Using a drive that has been secure erased to start
- Then rerun said script except implementing a pause between passes 1 and 2 (1minute, 1hr, 1day, your choice) to let GC do it's thing.


The results:
Test A will show a performance difference of about 10 - 20% between XP and 7 on pass 2. Pass 1 will be nearly identical between XP and 7 (clean drive).
Test B will show performance times between pass 1 and 2 as very close to each other.

 

[WyomingKnott]

"when the SSD sees the pointer removed" - unless there is a TRIM command, or the SSD understands the structure of the allocation table, how can it see that removed?

The horse is _very_ unhappy.

 

[psaus]

The horse is _very_ unhappy.

LOL, and smelly by now

Basically, the SSD has to control the physical allocation table, presenting a logical allocation table to the OS. This is because any OS on the market today will try to write data to those "outer ring addresses first" (no dyslexia for me today <- older post reference for those wondering). If an SSD didn't take control of this (wearleveling), an SSD would burn out very quickly.

My interpretation is that GC wakes up in idle times, does a reading of these "changes/pointer removals" then goes to work cleaning up. TRIM invokes GC to execute as soon as reasonably possible, giving GC the explicit information it needs to clean up, without needing to take the laborious steps of scanning the tables.

 

[WyomingKnott]

Just occurred to me

JohnnyLucky's avatar looks like he would _ride_ a dead horse.

 

[Kent Smith]

I ran across this forum post today and thought I would help any future readers with some details from the source. Some of the information above is completely true and some is a bit misunderstood. Below I have provided a number of entries to some of the questions I have seen in this and other related threads. I hope it provides useful information to the Tom’s Hardware readers in trying to better understand TRIM and Garbage Collection.

As for my credentials on this topic, I am the Sr. Director of Marketing and Performance Analysis for the division at LSI (soon to be owned by Avago) that makes the SandForce Flash controllers. I have presented many times at the Flash Memory Summit in Santa Clara, California, on the topic of SSD operations for many years. I also have a blog on www.blog.lsi.com covering all aspects of Solid State Drives.

1. Garbage collection (GC) explained: I go into greater detail in my 2011 Flash Memory Summit presentation http://www.lsi.com/downloads/Public/Flash%20Storage%20Processors/LSI_PRS_FMS2011_T1A_Smith.pdf , but for the short explanation flash memory is organized in groups of pages where data can be written. Once a page is written, it cannot be rewritten until it is erased. But a page can only be erased within a group of typically 128 pages called a block. The complexity of writing data really starts to escalate in the case of random writes replacing previously written data. Random writes put the new data in previously erased pages elsewhere, peppering a block of valid data with “patches of invalid data.” In order to write new data to these patches, the whole block – all 128 pages – must be erased. But first all surrounding pages with valid data must be read and then rewritten to blank pages. The newly erased block of blank pages is then ready to save new data.

2. All NAND Flash-based SSDs use GC. Some use foreground GC and some use background or idle-time GC. The difference between them is covered in my blog http://blog.lsi.com/dont-let-ssds-throw-away-your-gold/ . In simple terms background garbage collection will increase write amplification (WA) and wear out the SSD sooner. Foreground GC is harder to achieve and I believe only the SandForce controller is able to do it today.

3. Write Amplification is present in all SSDs, but there are many factors that affect it. I cover this in great detail in a three-part blog starting http://blog.lsi.com/write-amplification-part-1-why-ssds-hate-amplification/ . In summary because of GC moving valid data to new locations before erasing all data in a block, data is written multiple times inside the SSD flash wearing it out sooner. For this reason you want a drive with the lowest possible write amp.

4. TRIM is beneficial to all SSDs regardless of what kind of garbage collection is used. I talk about how TRIM came into existence and why it is necessary in my blog http://blog.lsi.com/did-you-know-hdds-do-not-have-a-delete-command-that-is-why-ssds-need-trim/ . The TRIM command is sent by the OS to the SSD to identify what pages of data can be ignored during garbage collection. The SSD cannot tell what files have been deleted until the OS uses the same sectors to store new files, but by that time the SSD has already wasted cycles by garbage collecting data that was invalid, but known to the SSD.

5. TRIM will benefit all SSDs in some way. Some will benefit more than others depending upon their situation.

5.1 TRIM will not help an SSD that is storing data to the full capacity of the available user space (e.g., saving 128GB of data on a 128GB SSD).

5.2 SSDs that use a data reduction technology like that in SandForce controllers benefit more from TRIM with high entropy data. With low entropy data there is already so much extra dynamic over provisioning that giving the SSD more space with TRIM under that condition provides diminishing returns; it will already be as fast as it can get. You can read more about this in http://www.lsi.com/downloads/Public/Flash%20Storage%20Processors/LSI_PRS_FMS2012_TE21_Smith.pdf

6. TRIM provides the same benefit as extra over provisioning. This is explained in detail in my blog http://blog.lsi.com/gassing-up-your-ssd/ . TRIM acts like a dynamic over provisioning.

7. TRIM is not supported in most RAID configurations due to complexities in tracking the data between the OS and RAID controller. RAID 1 is easier to support than RAID 5 or RAID 6. Wikipedia does a good job of tracking the RAID issue. http://en.wikipedia.org/wiki/TRIM#RAID_issues

8. The SSD is unaware of invalid data pages without the TRIM command from the OS. All major SSD controllers today support TRIM. All major operating systems today support TRIM. Wikipedia keeps good track of the OS list. http://en.wikipedia.org/wiki/TRIM#Operating_system_support

9. Garbage collection without TRIM will always be moving all invalid data during the GC process acting like the SSD is operating at full capacity. Only the TRIM command can identify the invalid data and improve performance.

10. A 128GB SSD with TRIM and only 64GB of user data will operate like an SSD with 64GB of over provisioning, meaning it will operate at its fastest level.

11. TRIM identifies what the OS no longer wants to save, but nothing changes on the SSD until the GC process actually recycles that block of pages and skips the TRIMed invalid data.

12. GC is not a replacement for TRIM regardless of foreground or background type. TRIM can only make the GC process more efficient and lower the write amplification.

I hope this helps everyone. I will do my best to track this thread to respond to any questions that may come up.

 

[Miroco]

TRIM or not to TRIM

Could the debate over the benefit of Trim more have to do how Trim is implemented in various operating systems than Trim itself?

http://www.howtogeek.com/176978/ubuntu-doesnt-trim-ssds-by-default-why-not-and-how-to-enable-it-yourself/

I ran across this forum post today and thought I would help any future readers with some details from the source. Some of the information above is completely true and some is a bit misunderstood. Below I have provided a number of entries to some of the questions I have seen in this and other related threads. I hope it provides useful information to the Tom’s Hardware readers in trying to better understand TRIM and Garbage Collection.

As for my credentials on this topic, I am the Sr. Director of Marketing and Performance Analysis for the division at LSI (soon to be owned by Avago) that makes the SandForce Flash controllers. I have presented many times at the Flash Memory Summit in Santa Clara, California, on the topic of SSD operations for many years. I also have a blog on www.blog.lsi.com covering all aspects of Solid State Drives.

1. Garbage collection (GC) explained: I go into greater detail in my 2011 Flash Memory Summit presentation http://www.lsi.com/downloads/Public/Flash%20Storage%20Processors/LSI_PRS_FMS2011_T1A_Smith.pdf , but for the short explanation flash memory is organized in groups of pages where data can be written. Once a page is written, it cannot be rewritten until it is erased. But a page can only be erased within a group of typically 128 pages called a block. The complexity of writing data really starts to escalate in the case of random writes replacing previously written data. Random writes put the new data in previously erased pages elsewhere, peppering a block of valid data with “patches of invalid data.” In order to write new data to these patches, the whole block – all 128 pages – must be erased. But first all surrounding pages with valid data must be read and then rewritten to blank pages. The newly erased block of blank pages is then ready to save new data.

2. All NAND Flash-based SSDs use GC. Some use foreground GC and some use background or idle-time GC. The difference between them is covered in my blog http://blog.lsi.com/dont-let-ssds-throw-away-your-gold/ . In simple terms background garbage collection will increase write amplification (WA) and wear out the SSD sooner. Foreground GC is harder to achieve and I believe only the SandForce controller is able to do it today.

3. Write Amplification is present in all SSDs, but there are many factors that affect it. I cover this in great detail in a three-part blog starting http://blog.lsi.com/write-amplification-part-1-why-ssds-hate-amplification/ . In summary because of GC moving valid data to new locations before erasing all data in a block, data is written multiple times inside the SSD flash wearing it out sooner. For this reason you want a drive with the lowest possible write amp.

4. TRIM is beneficial to all SSDs regardless of what kind of garbage collection is used. I talk about how TRIM came into existence and why it is necessary in my blog http://blog.lsi.com/did-you-know-hdds-do-not-have-a-delete-command-that-is-why-ssds-need-trim/ . The TRIM command is sent by the OS to the SSD to identify what pages of data can be ignored during garbage collection. The SSD cannot tell what files have been deleted until the OS uses the same sectors to store new files, but by that time the SSD has already wasted cycles by garbage collecting data that was invalid, but known to the SSD.

5. TRIM will benefit all SSDs in some way. Some will benefit more than others depending upon their situation.

5.1 TRIM will not help an SSD that is storing data to the full capacity of the available user space (e.g., saving 128GB of data on a 128GB SSD).

5.2 SSDs that use a data reduction technology like that in SandForce controllers benefit more from TRIM with high entropy data. With low entropy data there is already so much extra dynamic over provisioning that giving the SSD more space with TRIM under that condition provides diminishing returns; it will already be as fast as it can get. You can read more about this in http://www.lsi.com/downloads/Public/Flash%20Storage%20Processors/LSI_PRS_FMS2012_TE21_Smith.pdf

6. TRIM provides the same benefit as extra over provisioning. This is explained in detail in my blog http://blog.lsi.com/gassing-up-your-ssd/ . TRIM acts like a dynamic over provisioning.

7. TRIM is not supported in most RAID configurations due to complexities in tracking the data between the OS and RAID controller. RAID 1 is easier to support than RAID 5 or RAID 6. Wikipedia does a good job of tracking the RAID issue. http://en.wikipedia.org/wiki/TRIM#RAID_issues

8. The SSD is unaware of invalid data pages without the TRIM command from the OS. All major SSD controllers today support TRIM. All major operating systems today support TRIM. Wikipedia keeps good track of the OS list. http://en.wikipedia.org/wiki/TRIM#Operating_system_support

9. Garbage collection without TRIM will always be moving all invalid data during the GC process acting like the SSD is operating at full capacity. Only the TRIM command can identify the invalid data and improve performance.

10. A 128GB SSD with TRIM and only 64GB of user data will operate like an SSD with 64GB of over provisioning, meaning it will operate at its fastest level.

11. TRIM identifies what the OS no longer wants to save, but nothing changes on the SSD until the GC process actually recycles that block of pages and skips the TRIMed invalid data.

12. GC is not a replacement for TRIM regardless of foreground or background type. TRIM can only make the GC process more efficient and lower the write amplification.

I hope this helps everyone. I will do my best to track this thread to respond to any questions that may come up.

 

[Kent Smith]

TRIM or not to TRIM

Could the debate over the benefit of Trim more have to do how Trim is implemented in various operating systems than Trim itself?

http://www.howtogeek.com/176978/ubuntu-doesnt-trim-ssds-by-default-why-not-and-how-to-enable-it-yourself/

Nice find and great information. I had not previously seen that information on Ubantu, but there could still be more to that story. The TRIM command is well defined, but it does give some flexibility around how to tell the SSD what locations are no longer valid (one location at a time or a sting of locations). What is not controlled by the command is "when" the OS sends TRIM to the SSD and "when and how" the SSD processes the information. That link notes poor results from TRIM in Ubantu, but does not detail how the tests were conducted. While it is possible Ubantu may not perform well with TRIM, there are other variables that could affect the outcome. Different SSDs may behave differently. The source quoted in the post notes SSDs from 2011. That was a time when many SSD controllers had other issues around TRIM. Further testing would be interesting to better understand the issue with today's SSD controllers now 3 years later (a lifetime for emerging technologies).

I should note a point of clarification in that post on why TRIM is important. It is true SSDs cannot overwrite data directly and must first erase "blocks" of "pages" before a previously written page can be overwritten with new data. But, the performance gain after TRIM comes from two places. First, TRIM tells the SSD to stop tracking invalid data during garbage collection. This speeds up the garbage collection process. Second, the pages of data that are now freed up will automatically turn into "dynamic" over provisioning. Since larger amounts of over provisioning will improve SSD performance, this increased dynamic over provisioning helps as well. These points are covered in more detail in my prior post above under points 4-6.

The recommendation to run the fstrim as a background operation is fine and should result in the same performance improvement after it is complete. The invalid data will be known to the SSD, enabling it to ignore it during further garbage collection processes and allow the dynamic over provisioning to increase.