Solved SSD TRIM versus garbage collection

[RazorEdge]

I'm trying to understand this and have scoured the web and asked all the AI chatbots to no avail:

What is the purpose of the TRIM feature in SSDs when they already have the garbage collection feature?

My understanding of garbage collection is:

• SSD data is read and written at the page level but must be erased at the block level
• Garbage collection identifies stale pages within blocks, moves non-stale data to another block, then erases the block. This often runs when SDD activity is low
• The purpose of garbage collection is to increase efficiency by keeping as many empty blocks as possible so that, when the SSD has to write data, it doesn't have to wait for a block to be erased

My understanding of TRIM is that the OS proactively informs the SSD controller which data blocks can be deleted so the garbage collection process can manage these pages more efficiently.

But this seems completely redundant - when new data is being written, the SSD controller is communicating with the OS to write new pages and mark the old pages as stale. Why does the OS need to tell the SSD controller again that these pages are stale and can be deleted? Does the SSD controller not mark the old pages as stale immediately? If not, what is the (non-TRIM) process for marking pages as stale?

Any help is appreciated, cheers

 

[AlphaObeisance]

the purpose of TRIM versus garbage collection in SSDs. Let's break it down:

Garbage collection in SSDs is responsible for managing data at the block level. SSDs can read and write data at the page level, but they must erase entire blocks before they can be rewritten. When you delete data from an SSD, the operating system (OS) marks the corresponding pages as stale. However, the SSD's garbage collection process itself doesn't immediately erase these stale pages. Instead, it identifies blocks that contain a significant amount of stale data during idle times and moves the valid data to new blocks. It then erases the entire old block, making it ready for new data.

TRIM is a command that allows the OS to proactively inform the SSD which blocks of data are no longer in use (marked as stale) after files have been deleted or modified. Without TRIM, the SSD would only learn about stale data when it tries to write new data to a block containing stale pages. This process can be less efficient because the SSD would have to perform garbage collection on-the-fly during write operations, potentially slowing down performance.

The key benefit of TRIM is efficiency. By issuing TRIM commands, the OS helps the SSD's garbage collection process work more proactively. Instead of waiting for the SSD to discover stale data during write operations, the OS tells the SSD in advance which data blocks are no longer needed. This allows the SSD to perform garbage collection more effectively during idle times, ensuring that more blocks are pre-erased and ready for new data when write operations occur.

You might wonder why the OS needs to tell the SSD about stale data if the SSD already knows when pages are marked as stale during write operations. The difference lies in timing and efficiency. Without TRIM, the SSD learns about stale data reactively during writes, potentially causing delays. TRIM allows the SSD to anticipate which blocks will need garbage collection, optimizing performance and extending the SSD's lifespan by reducing write amplification (a phenomenon where extra writes are needed due to inefficient data management).

In summary, TRIM and garbage collection complement each other by ensuring that SSDs operate efficiently. TRIM helps the OS communicate stale data to the SSD proactively, optimizing garbage collection and enhancing overall performance and longevity of the SSD.

Hope this brings some clarity to the table ^_^

 

[bob466]

I'm trying to understand this and have scoured the web and asked all the AI chatbots to no avail:

What is the purpose of the TRIM feature in SSDs

You didn't look very far...
https://www.baeldung.com/linux/trim-ssd
https://www.baeldung.com/linux/solid-state-drive-optimization
https://www.fosslinux.com/126140/mastering-fstrim-a-linux-command-for-ssd-optimization.htm

This is really all you need to know. I have Trim set to run daily and now and then I'll run this command...

sudo fstrim -v /

You can also run this command for Portable SSD too...simple.

 

[RazorEdge]

While I appreciate the responses (and it wouldn't be a proper forum post here without someone knocking my research abilities ), this hasn't actually answered my question.

I've read through all the linked articles here:

You didn't look very far...
https://www.baeldung.com/linux/trim-ssd
https://www.baeldung.com/linux/solid-state-drive-optimization
https://www.fosslinux.com/126140/mastering-fstrim-a-linux-command-for-ssd-optimization.htm

And looked at this (and can't help but think it's an AI generated answer):

You might wonder why the OS needs to tell the SSD about stale data if the SSD already knows when pages are marked as stale during write operations. The difference lies in timing and efficiency. Without TRIM, the SSD learns about stale data reactively during writes, potentially causing delays. TRIM allows the SSD to anticipate which blocks will need garbage collection, optimizing performance and extending the SSD's lifespan by reducing write amplification (a phenomenon where extra writes are needed due to inefficient data management).

I get that what I'm asking is very granular, but I still do not understand this part of my original question (expanded for clarity):

When new data is being written to a SSD, the SSD controller is communicating with the OS to write new pages and mark the old pages as stale. This happens immediately right? No TRIM involved, just normal SSD controller operations.

Why does the OS need then need TRIM to tell the SSD controller again that these pages are stale and can be deleted? Does the SSD controller not mark the old pages as stale immediately when data is updated or deleted?

What is the (non-TRIM) process for marking pages as stale?

Is anyone able to help with this?

 

[bob466]

When new data is being written to a SSD, the SSD controller is communicating with the OS to write new pages and mark the old pages as stale. This happens immediately right? No TRIM involved, just normal SSD controller operations.

Why does the OS need then need TRIM to tell the SSD controller again that these pages are stale and can be deleted? Does the SSD controller not mark the old pages as stale immediately when data is updated or deleted?

What is the (non-TRIM) process for marking pages as stale?

Is anyone able to help with this?

Maybe you should ask the Manufactures.

 

[osprey]

While I appreciate the responses (and it wouldn't be a proper forum post here without someone knocking my research abilities ), this hasn't actually answered my question.

I've read through all the linked articles here:


And looked at this (and can't help but think it's an AI generated answer):


I get that what I'm asking is very granular, but I still do not understand this part of my original question (expanded for clarity):

When new data is being written to a SSD, the SSD controller is communicating with the OS to write new pages and mark the old pages as stale. This happens immediately right? No TRIM involved, just normal SSD controller operations.

Why does the OS need then need TRIM to tell the SSD controller again that these pages are stale and can be deleted? Does the SSD controller not mark the old pages as stale immediately when data is updated or deleted?

What is the (non-TRIM) process for marking pages as stale?

Is anyone able to help with this?

The garbage collection process occurs automatically, usually during a system idle.

Trim, on the other hand needs to provide the ssd with the information about its deleting of files and that those file pages need to be made available for new information.

So it's partially a timing matter, the ssd controller's activity occurs according to its own scheduled algorithm which is not going to always coincide with the timing of the operating system's information provision about file processes which trim can inform it about.

The two processes therefore work together to achieve the outcome of a more effective management of the ssd.

 

[Condobloke]

fwiw ....I use

 sudo fstrim -av

which then shows....

brian@brian-desktop:~$ sudo fstrim -av
[sudo] password for brian:
/boot/efi: 504.9 MiB (529436672 bytes) trimmed on /dev/nvme0n1p1
/: 31.9 GiB (34231144448 bytes) trimmed on /dev/nvme0n1p2
brian@brian-desktop:~$

 

[KGIII]

I was an early SSD adopter. I'd sometimes run trim manually but, AFAIK, it was included with the kernel in version 2.14 (a LTS variant) and I don't think I've bothered with manually running it since. Even before that, the SSD's firmware itself dealt with it just fine.

My first SSD, to put it in perspective, wasn't even a full SSD. It was a hybrid with an HDD. So, I've used SSDs for a long time - probably about as long as I've been using Linux (some 15+ years now).

 

[RazorEdge]

Thanks osprey, this makes sense:

So it's partially a timing matter, the ssd controller's activity occurs according to its own scheduled algorithm which is not going to always coincide with the timing of the operating system's information provision about file processes which trim can inform it about.

I appreciate the help everyone