Can TRIM work on a drive that never rests?

[wpcoe]

I've noticed that my hard drive light blinks a steady 1x/second even when I would expect the system to be idle. I booted (Win7 HP 64-bit, if it matters) into Safe Mode and in Task Manager there are only 22 processes and none of them show any activity under I/O Reads/Writes/Other but the light still blinks at a steady rate. Even logging off and letting the screen show the log-on screen: blink, blink, blink, even overnight.

Now, I don't know if it's my SSD or one of my HDDs, but being a pessimist, I will assume it's the SSD. If so, will TRIM *ever* get a chance to do its work? What about the drive doing its own garbage collection? (Intel 520)

Of course, I would like to know why my drive light pulses like that, if for no other reason than curiosity, but I'm foremost concerned about TRIM/GC.

If TRIM/GC can't work during constant drive activity in Windows, would at least GC work if I pause at the BIOS boot process before Windows loads? If so, how long should I pause? Overnight? A few hours?

 

[Coup27]

To start, TRIM is a command sent to the SSD to mark which blocks can be erased by GC next time there is idle, so aslong as you have the current RST and empty your recycle bin from time to time then the TRIM command will happen. But you are correct that if your drive constantly reading or writing to it, then garbage collection will not effectively run.

Open task manager and then resource monitor. Go into disk and do some investigating on why the HDD activity light is always on.

Edit I just remembered you said "one of my hard drives" - unplug all of your HDDs and boot the system and see if the light stops flashing.

Leaving your system in BIOS for 10 minutes at most should complete GC. Unfortunately there are no figures on "how long is long enough" but my Samsung SSD magician runs TRIM and GC together and that takes 3 minutes for 128GB.

I did email Kristian Vatto about AT doing an in-depth "real world" example of TRIM and GC and he showed an interest but I think Anand kyboshed the idea.

 

[Jocelyn84]

I'd like to know about this as well. The M3 is the only disk in my system and my hdd activity light always blinks every 2-3 seconds even when I'm logged out. I've run file recovery utilities to see if trim/gc was working, and sure enough within a few minutes, the files were no longer recoverable. I still wish I knew why my activity led is always blinking during idle.

Sent from my Samsung Epic 4G Touch using Tapatalk

 

[Elixer]

I'd like to know about this as well. The M3 is the only disk in my system and my hdd activity light always blinks every 2-3 seconds even when I'm logged out. I've run file recovery utilities to see if trim/gc was working, and sure enough within a few minutes, the files were no longer recoverable. I still wish I knew why my activity led is always blinking during idle.

Sent from my Samsung Epic 4G Touch using Tapatalk

Why wouldn't it show activity ?
Windows still does things behind the scenes when "idle"... in fact, the only time it should stop to show activity is if you are in sleep / hibernation mode, or you are using a RAM disk for everything, unless you have DIMMs with LEDs on it that show activity.

You can also boot into the BIOS screen, and your SSD should do gc then, and you won't see any activity unless the BIOS polls the drive.

 

[BrightCandle]

Resource Monitor will show up which program is producing that disk access. Its not normal that with nothing running that you see constant access so you should track it down. If it doesn't show up in Windows Resource monitor then windows doesn't think it or any program its running it is doing it....which points to a malicious piece of software.

 

[corkyg]

If Indexing is alive, then that can be the source of the constant activity. And, System Restore can be creating Shadow Copies on the drive. Check your processes.

 

[VirtualLarry]

I know XP used to poll the CD/DVD drive for a Media Change Notification, like every second.

If you have an optical drive installed, then that may be the source of the activity.

 

[Jocelyn84]

Resource Monitor will show up which program is producing that disk access. Its not normal that with nothing running that you see constant access so you should track it down. If it doesn't show up in Windows Resource monitor then windows doesn't think it or any program its running it is doing it....which points to a malicious piece of software.

I actually tested with a stop watch program on my phone, and it's only blinking every minute while in idle or logged out. I was way off with 2-3 seconds. The blue led is so bright that it feels like it's always on lol. Maybe I'll disconnect it. Anyway, is activity every minute or so (sometimes a few minutes between each blink) normal while logged out?

If Indexing is alive, then that can be the source of the constant activity. And, System Restore can be creating Shadow Copies on the drive. Check your processes.

Indexing is completely off in indexing options, however I believe search indexing is on. I also don't have recovery/system restore enabled, as I back everything up externally.

I know XP used to poll the CD/DVD drive for a Media Change Notification, like every second.

If you have an optical drive installed, then that may be the source of the activity.

No optical drive, but maybe that's the OPs problem...

Thank you for all the input everyone...

 

[taltamir]

To start, TRIM is a command sent to the SSD to mark which blocks can be erased by GC next time there is idle, so aslong as you have the current RST and empty your recycle bin from time to time then the TRIM command will happen. But you are correct that if your drive constantly reading or writing to it, then garbage collection will not effectively run.

it is worth noting that if trim is working, then idle time GC has absolutely nothing to do.

I would have guessed constant small access comes from a program making a log file but you say it still does that in safe mode which is odd

 

[VirtualLarry]

it is worth noting that if trim is working, then idle time GC has absolutely nothing to do.

This is not true.

Some drives perform clean-up, when TRIM is sent. Other drives, use TRIM to mark pages for future GC, and actually do the clean-up during idle-time GC.

 

[Coup27]

This is not true.

Some drives perform clean-up, when TRIM is sent. Other drives, use TRIM to mark pages for future GC, and actually do the clean-up during idle-time GC.

I also thought this to be the case..?

 

[BrightCandle]

If its minutes rather than seconds then that is pretty normal idle activity for Windows. Linux has a 10 second cycle so you often see activity periodically there as well.

Your SSD will be running GC in milliseconds of inactivity rather than seconds anyway. It can take it potentially hours to clean up a really big mess but it'll do it in very small individual chunks such that even when you think you are using your computer heavily it'll find time. Computers "think" in nanoseconds and SSDs in microseconds. You don't notice the microseconds your idle I promise you! GC is probably working completely normally.

I love Anandtech's deep analysis of the SSD problems and quirks he's done a fantastic job. The problem is that its put everyone in fear of running their SSD's out of space, not being GCed correctly etc. In reality all this stuff just works and you need to do absolutely nothing to make it do so.

If you ignore you have an SSD you can finally start to see the benefits. The next time you are on a machine with a HDD then you'll suddenly realise the difference.

 

[wpcoe]

I disconnected both my HDDs, booted with just the SSD into Windows 7 Safe Mode and still get a constant one blink per second on the hard drive light. With Task Manager open and showing processes from all users, no process shows any IO activity (read/write/other). Indexing is off, and anti-virus/firewall don't load in Safe Mode, so I have NO idea what is keeping my SSD busy.

Some drives perform clean-up, when TRIM is sent. Other drives, use TRIM to mark pages for future GC, and actually do the clean-up during idle-time GC.

Interesting. Do you know if the Intel 520 does immediate clean-up when the TRIM command is sent?

If Indexing is alive, then that can be the source of the constant activity. And, System Restore can be creating Shadow Copies on the drive. Check your processes.

While I usually have indexing turned on, I turned it off to eliminate it as the culprit. Still blinks with indexing off.

I know XP used to poll the CD/DVD drive for a Media Change Notification, like every second.

If you have an optical drive installed, then that may be the source of the activity.

<sigh...> Guess I'll take the machine apart again and try with no DVD drive attached.

Resource Monitor will show up which program is producing that disk access. Its not normal that with nothing running that you see constant access so you should track it down. If it doesn't show up in Windows Resource monitor then windows doesn't think it or any program its running it is doing it....which points to a malicious piece of software.

Totally forgot about Resource Monitor. So, I will rip the thing open, disconnect the HDDs *and* the DVD, boot into Safe Mode and check Resource Monitor.

Stay tuned! (or not...)

 

[groberts101]

decent advice from all so far.

I've seen many users who are overly concerned with activity lights under the assumption that GC will not function. This is a completely false assumption since GC rarely requires absolutely NO activity to function. It only requires REDUCED write activity with enough time given to function fairly consistently and make progress for block recovery.

If the main requirement was NO activity whatsoever?.. people would be having major issues across the net due to all the invasive background tasks that AV and Windows itself is known for. Mfgrs know how the typical user is going to implement their devices and have made the necessary tweaks to allow it to function when activity is low enough.

And as Coup already said.. TRIM is near immediate.. GC is what takes time on most controllers. How aggressive GC is will always be dependant on the controller and the amount of fresh blocks available on the drive. The fuller or dirtier the drive?.. the more aggressive it becomes based on internal algorithms built into the firmware.

That being said.. Sandforce is not very aggressive as to when it will allow GC to occur. It often does it in a very lazy and deferred manner compared to all others. This is why overprovisioning and idle recovery can be so effective for this controller as it makes up for those inherent weaknesses.

The ONLY time a Sandforce 228x based drive will allow aggressive GC(also called on-the-fly recovery) is when the drive is nearly completely spent of all fresh blocks(and that is regardless of TRIM availability or not). Obviously not a good place to be with the state of any SSD, but for most typical users it is barely noticable even when fully degraded and is considered to be one of the strengths for this controller.

Case in point.. the first gen SF controller would stay throttled for quite some time with added latency and 50% losses in incompressible write speeds. This newest version.. not nearly as much since it can release throttles nearly instantly as it frees blocks much more aggressively due to its tweaked GC algorithms which are a direct result of its larger recycling engine.

Personally?.. my money is on the optical drive causing the activity light to give false positive for OS drive activity. GC will still work just the same regardless of that LED's status.

 

[taltamir]

This is not true.

Some drives perform clean-up, when TRIM is sent. Other drives, use TRIM to mark pages for future GC, and actually do the clean-up during idle-time GC.

Wrong. Neither trim not GC directly result in immediate cleaning up of sectors, other then erase blocks which contain 100% deleted data, those are cleaned up immmediately.
I just had this argument with someone and I double checked and got a ton of documentation backing it up (in that other thread, was it per chance you I argued this with?).

TRIM (trim is not an acronym btw) = When a file is deleted, the drive is notified immediately so it knows to mark those sectors as containing junk data. It does NOT immediately clear them, rather, when it does clear them eventually it does not bother retaining the junk data.

Idle Time Garbage Collection = When the drive has idled for a certain amount of time, it will query the filesystem IF AND ONLY IF the drive is formatted in a known file system (typically NTFS and FAT32) and locate sectors marked as containing deleted data on the FS, it will then mark them as containing junk data but will not clear them immediately. Rather when it does clear them it will not bother retaining the junk data.

Since TRIM instantly informs the drive on every deletion 100% of the time, IDGC has absolutely nothing to do and does absolutely nothing for you.
Actually recovering sectors for usage is NOT called GC.
And as the drive is fully informed of exactly what is going the controller can plan ahead to minimize write amplification.

 

[groberts101]

you are making assumptions here once again. There is no such thing as "Idle Time Garbage Collection". Only GC that is allowed to function DURING Idle time.

Big.. HUGE.. difference and is all based on internal algorithms set forth by the controller mfgr(although there is some slight leeway in adjustment from each individual mfgr who decides to utilize that particular controller).

GC can be done whenever the drive see's fit and is based on the internal algorithms of the controllers firmware. Deffered recovery(such as idle time), immediate(also called "on-the-fly"), and even lighter intermittent recovery algorithms based on GB written over time are all being implemented by various controller mfgrs basecode these days.

You are simply over specifying what GC is.. and when it can be implemented. When a drive has no TRIM pass-through?.. it relies on all the GC implementations mentioned above. The drive also does not require full idle with 0% disk activity for it to function either. That just improves the efficiency level since no additional writes are ocurring and it can recover more quickly since more blocks are not being dirtied during the recovery process. Basically, a full 3 steps forward.. instead of 3 steps forward and 1 step back.

 

[Old Hippie]

I just had this argument with someone and I double checked and got a ton of documentation backing it up (in that other thread, was it per chance you I argued this with?).

I'd like to see the documentation in the other thread.

A poster on another forum was inquiring about TRIM & timing but I'd like to see your documentation that EVERY manfg implements it the same manner.

 

[wpcoe]

Wow. I'm too tired now to really absorb what is being said above, but I think when I have a clear mind I will have a much better understanding of GC/TRIM. (Not an acronym??? 😱 )

The one-flash-per-second culprit was the DVD drive. Since I really don't use the DVD drive very much, I just disabled it in Device Manager. If/when I need it, I'll just enable it.

Also found out that when a drive is attached to the PCIe SATA card that my mobo doesn't detect drive activity to send it to the red HDD light on the case.

Thanks to everybody who has commented so far! :thumbsup:

PS: I'm not even going to pursue why, only in the past week, my DVD drive started doing whatever it's doing to trigger those one-second flashes.

 

[taltamir]

I'd like to see the documentation in the other thread.

A poster on another forum was inquiring about TRIM & timing but I'd like to see your documentation that EVERY manfg implements it the same manner.

http://forums.anandtech.com/showthread.php?t=2233200
That thread contains all the links, quotes, etc.
Also, the guy I was arguing with is groberts101

This isn't a matter of implementation its a matter of understanding what TRIM and GC means.

The algorithms are different but what I described are things that are universal. Whether GC is always on or Idle time only, GC does not, never has, and never will refer to the block recycling path.
It refers solely to the act of quering the filesystem for deleted files to mark their sectors as containing deleted data...
This is then used by the controllers various algorithms as it sees fit in a manner the differs from controller to controller.

TRIM is superior because unlike GC All data is marked as deleted the instant it is deleted, the earlier it is marked the better the drive can plan ahead. At absolute worse GC would merely equal TRIM.
IIRC all GC is done in idle time but it is entirely possible to have GC running while the user is using the drive, it would not make a difference though to the fact that TRIM is better.

You are simply over specifying what GC is.. and when it can be implemented. When a drive has no TRIM pass-through?.. it relies on all the GC implementations mentioned above. The drive also does not require full idle with 0% disk activity for it to function either. That just improves the efficiency level since no additional writes are ocurring and it can recover more quickly since more blocks are not being dirtied during the recovery process. Basically, a full 3 steps forward.. instead of 3 steps forward and 1 step back.

You are simply inventing incorrect definitions for what GC is. You don't get to simply make up definitions for GC that are untrue. I provided ample links showing you to be wrong in that other thread and you showed not a single shred of evidence.
The block recycling path is not and never has been a part of GC. It uses information acquired from GC, but GC is only for finding and marking data as deleted in the controllers charts so it will then know how to deal with it correctly.
A block that has all sectors in it marked as containing deleted data should be cleared ASAP and it is most likely triggered immediately as TRIM or GC marks it as such, but that doesn't make it a PART of TRIM or GC. Often the controller will not have the luxury of clearing wholly useless data and would have to engage in read-modify-erase-write cycle for a block, when this happens it would want to choose a block that has a minimal amount of data on it (but also takes into consideration wear leveling) and making the best choice here requires that the controller know what data is deleted junk, and that requires TRIM or GC.

The definition of what is part of TRIM or GC is completely arbitrary, as those are just names invented by humans. But they are not yours to redefine as you see fit.

 

[VirtualLarry]

This isn't a matter of implementation its a matter of understanding what TRIM and GC means.

The algorithms are different but what I described are things that are universal. Whether GC is always on or Idle time only, GC does not, never has, and never will refer to the block recycling path.
It refers solely to the act of quering the filesystem for deleted files to mark their sectors as containing deleted data...
This is then used by the controllers various algorithms as it sees fit in a manner the differs from controller to controller.

TRIM is superior because unlike GC All data is marked as deleted the instant it is deleted, the earlier it is marked the better the drive can plan ahead. At absolute worse GC would merely equal TRIM.
IIRC all GC is done in idle time but it is entirely possible to have GC running while the user is using the drive, it would not make a difference though to the fact that TRIM is better.



You are simply inventing incorrect definitions for what GC is. You don't get to simply make up definitions for GC that are untrue. I provided ample links showing you to be wrong in that other thread and you showed not a single shred of evidence.
The block recycling path is not and never has been a part of GC. It uses information acquired from GC, but GC is only for finding and marking data as deleted in the controllers charts so it will then know how to deal with it correctly.
A block that has all sectors in it marked as containing deleted data should be cleared ASAP and it is most likely triggered immediately as TRIM or GC marks it as such, but that doesn't make it a PART of TRIM or GC. Often the controller will not have the luxury of clearing wholly useless data and would have to engage in read-modify-erase-write cycle for a block, when this happens it would want to choose a block that has a minimal amount of data on it (but also takes into consideration wear leveling) and making the best choice here requires that the controller know what data is deleted junk, and that requires TRIM or GC.

The definition of what is part of TRIM or GC is completely arbitrary, as those are just names invented by humans. But they are not yours to redefine as you see fit.

You are completely wrong about garbage collection. It does not matter what filesystem is in use on the drive. It would be pretty damn stupid of drive mfgs, to make block-oriented storage devices, that use a standardized protocol, that works with multi operating systems, and then design their firmware around only a couple of popular filesystems.

GC has nothing to do with filesystems.

It does, however, have to do with the drive internally cleaning out it's "dirty block list", and erasing pages and whatnot, basically internally defragmenting stuff, and resulting in fresh clean pages for the drive to write to.

TRIM is input into this process. It allows the drive to mark a sector as deleted, even when not overwritten. When a sector is otherwise overwritten during normal usage, the old one is also marked for deletion/erase/cleanup.

TRIM does not cause the drive to immediately defrag/clean that block. Especially, since there may be other blocks in that page that contain working data. (Drive dependent)

 

[taltamir]

You are completely wrong about garbage collection. It does not matter what filesystem is in use on the drive. It would be pretty damn stupid of drive mfgs, to make block-oriented storage devices, that use a standardized protocol, that works with multi operating systems, and then design their firmware around only a couple of popular filesystems.

GC has nothing to do with filesystems.

It does, however, have to do with the drive internally cleaning out it's "dirty block list", and erasing pages and whatnot, basically internally defragmenting stuff, and resulting in fresh clean pages for the drive to write to.

TRIM is input into this process. It allows the drive to mark a sector as deleted, even when not overwritten. When a sector is otherwise overwritten during normal usage, the old one is also marked for deletion/erase/cleanup.

TRIM does not cause the drive to immediately defrag/clean that block. Especially, since there may be other blocks in that page that contain working data. (Drive dependent)

No, you are wrong. Erasing blocks is the block recycling engine is a completely seperate system from GC. GC only deals with marking sectors as containing junk data so that they will not cause more write amplification when that block is recycled.

And it is filesystem specific. This is not because that is a DESIRABLE thing, it is because THAT IS THE ONLY WAY TO DO IT.
This is because if you delete a file from an NTFS partition then the ONLY place where this deletion is registered is in the NTFS itself.

And it isn't stupid because they have TRIM, TRIM is the prefered method of doing things. THE ONLY purpose of GC is to gives something to people using older versions of window who refuse to upgrade.
Windows 7 and current versions of linux and FreeBSD (v9+) all have TRIM and as such never use GC, GC was a stopgap measure while TRIM is being adopted, nothing more.
Macs, Solaris, and older versions of the above 3 OS types are the only people who use GC.

 

[Mark R]

There is a lot of confusion in this thread. Let me clarify a few issues.

All (almost) SSDs are overprovisioned. This means that they have more flash memory available than they report to the OS. This allows the SSD to recycle blocks of flash more efficiently. The problem with flash is that while you can write (once) to individual sectors (pages), erasing can only be performed in large batches (blocks). Erasing is time consuming, and is necessary before a sector can be rewritten.

Without overprovisioning (and wear levelling, but that's another matter), if the OS wrote over the top of a sector, the SSD would need to copy the whole page (0.5-1 MB) into RAM, erase the whole page, then copy the whole page back with the modified sector. This is painfully slow, and converts a 4k write into a 1 MB write.

With overprovisioning, the overwrite can go into an unused block of flash memory; this is fast. The SSD can then note that the old sector is invalid. Once all the sectors in that block are noted as invalid, the block is erased and released for reuse. This avoids write amplification. Also, performance is improved by avoiding slow erase operations. (In practice, the spare flash will usually start to run out first, in that case, the block with the most invalid pages is erased, after first copying out the valid pages).

The issue now is when the recycling takes place. 1st generation drives would perform recycling during write operations. When there number of invalid sectors or spare flash level reached a preset limit, the drive would trigger a recycle process on the next write. The recycle would free up some blocks of freshly erased flash memory. The result was that once all the flash on the drive had been used once, the drive would slow down from its new state, as almost every write would trigger a recycle.

The next step was background recycling (also called garbage collection). The 2nd gen drive controllers, instead of only triggering a recycle operation when a write was issued, would, when idle, periodically recycle a few blocks, to ensure that the inventory of erased free blocks was kept to a reasonable level. This minimised the need for recycling when the drive was active, so kept performance closer to "new" levels. Drives could temporarily reduce in performance after being heavily thrashed, so that they were forced to recycle while in use.

Drives vary in what constitutes "idle". Some need a few seconds of idle time, some may only need a few miliseconds of idle time before triggering a recycle process.

Note that idle GC has nothing whatsoever to do with the filesystem; there is no interaction with the OS; no querying; no software; nothing.

The 3rd gen SSDs featured the TRIM command. The TRIM command allows the OS to tell the drive that it has finished with a particular sector, and that the drive is free to destroy that data if it wants. How drives deal with TRIM varies, according to how much data has been TRIMmed and also from drive to drive. For a single sector or a few sectors (< 1MB), what happens is that the drive simply notes the sector as invalid. The next time the drive performs a recycle, it will be able to free up more blocks for erasure, as TRIMmed sectors will be able to participate (not just overwritten sectors). In the event that a TRIM command is issued on a large file, and the TRIMmed area involves entire erase blocks, most drives will immediately recycle those entire blocks (although some might mark them for recycling, and only recycle them as part of their normal recycling process).

Summary
So, in effect, TRIM and GC are the same thing; the recycling of flash memory where the drive knows that the contents are unwanted. In the case of GC, the drive knows the contents are irrelevant because the drive, itself, is hiding the data from the OS (because it has more flash than it shows to the OS). In the case of TRIM, the drive knows the data is irrelevant because the OS has told the drive, that it no longer cares for the data.

If your drive is always being thrashed, its performance may drop even with TRIM as the drive is forced perform time-consuming block recycling while it is in use. However, TRIM will always be beneficial in terms of wear levelling (as the drive will not repeatedly copy/preserve TRIMmed data). Decent drives will try to delay the slow recycling process until the drive is idle.

 

[taltamir]

The next step was background recycling (also called garbage collection). The 2nd gen drive controllers, instead of only triggering a recycle operation when a write was issued, would, when idle, periodically recycle a few blocks, to ensure that the inventory of erased free blocks was kept to a reasonable level. This minimised the need for recycling when the drive was active, so kept performance closer to "new" levels. Drives could temporarily reduce in performance after being heavily thrashed, so that they were forced to recycle while in use.

Drives vary in what constitutes "idle". Some need a few seconds of idle time, some may only need a few miliseconds of idle time before triggering a recycle process.

Note that idle GC has nothing whatsoever to do with the filesystem; there is no interaction with the OS; no querying; no software; nothing.

File-system and OS are completely separate things. GC has nothing to do with the OS but nobody ever claimed it did. FS is a completely different thing and GC IS FS specific.

Also your assertion that GC is using clearing up space available with overprovision is wrong on 2 counts:
1. GC works perfectly fine in drives without overprovisioning (yes, they exist).
2. If it worked as you said it would have abhorrent write amplification.

Without the drive being aware of what is trash and what isn't, every 4kb write would cause a write amplification of 128. Intel drives average under 1.5 so that is 2 orders of magnitude difference.

So, in effect, TRIM and GC are the same thing;

Sorta correct, yes they do the same thing only TRIM does it better.
[quote[the recycling of flash memory where the drive knows that the contents are unwanted.[/QUOTE]
No, this is the block recycling engine, TRIM and GC only mark data as deleted in the virtualization table of the SSD.

Seriously guys, I linked an anandtech article, read it.

 

[Coup27]

I really wish I hadn't read any of this thread before trying to go sleep (1am).

After reading this thread, and the previous one linked by taltamir, and the AT articles linked to and a quick refresh of the "SSD Relaspe" , I do believe that taltamir is correct.

I think "garbage collection" has been a collective term has been incorrectly used by many (including me) to describe the block recycling system. Taken from the SSD Relaspe when talking about GC:

"The second scenario requires a compatible file system (allegedly NTFS for the Samsung drives) and then the data is actually TRIMed as it would be with the TRIM instruction."

So I do believe he is correct. GC was a prior-TRIM way of querying the file system to mark pages as "no longer required". The controller would then, based on it's algorithms clean these blocks at a suitable time as to minimise write amp when writing new pages and to maintain performance.

TRIM is a command sent when a file is actually deleted, so this means (under Windows) either a format, empty the recycle bin, or shift+del. TRIM will tell the controller which pages can be cleaned at its convenience. So I do believe that with active TRIM, GC will have nothing to do as TRIM will already have done it. When the controller does decide to clean the blocks is an entirely seperate process and is not called TRIM or garbage collection.

 

[Mark R]

File-system and OS are completely separate things. GC has nothing to do with the OS but nobody ever claimed it did. FS is a completely different thing and GC IS FS specific.

Also your assertion that GC is using clearing up space available with overprovision is wrong on 2 counts:
1. GC works perfectly fine in drives without overprovisioning (yes, they exist).
2. If it worked as you said it would have abhorrent write amplification.

Without the drive being aware of what is trash and what isn't, every 4kb write would cause a write amplification of 128. Intel drives average under 1.5 so that is 2 orders of magnitude difference.

There are rumors that there is FS specific GC, such as the anandtech article (which doesn't actually do the experiment that would show whether it was true or not). However, I've seen nothing concrete from a 1st-hand source.

I have asked a number of people who are in a position to know, and the reply is always "This is confidential information under NDA".

It would be very dangerous for a drive manufacturer to impute anything about the data structure on a drive (e.g. that a drive is in NTFS). What would happen if I used a RAID card/software to place 2 such drives in RAID 0? If the GC really did work as you stated, you would get guaranteed data corruption. Still, Samsung is the manufacturer rumored to have done this, and they have a reputation in storage circles as releasing drives with seriously broken firmware where they have tried to be clever (e.g. there was a series of drives a few years ago with completely broken writeback caching - this was never fixed or acknowledged, you just had to avoid them if you were using them with enterprise controllers).

As regards write amplification - even 0% overprovisioned drives still have some spare space (0% is just marketing speak for <1%). And because of statistics (if there are lots of free flash blocks( as TRIM can provide, or if a drive is heavily overprovisioned) a huge number of invalid sectors can be collected before any recycling takes place), and the fact that random 4k writes are uncommon (most are >4k or are correlated or sequential), the actual WA is much reduced from the theoretical max of 128. However, if you do look at 1st gen SSDs (like the original indilinx barefoot), then WA of 40-80 was pretty typical for those drives.