Viewing a single comment thread. View all comments

sauprankul t1_iy4hqkl wrote

This is misleading. TRIM does not immediately "clear" ie "set to 0" deleted pages. They simply mark them as "do not collect" for garbage collection. This way, when the GC algorithm runs, it doesn't copy over the useless pages to new blocks. However, afaik, SSDs never actually destroy deleted pages unless overwritten by new data.

4

LlamadeusGame t1_iy4j2t8 wrote

It's a distinction without a difference. The drive gets managed during garbage collection, as in a block is copied and reorganized to a different block so the old block can be cleared (e.g. set to 0).

TRIM tells the drive "hey don't bother copying this stuff, and clear it with the rest of this block " effectively deleting it, not just delisting it. Garbage collection is(effectively) constant, and deleting a file is going to clear many many blocks, causing those blocks to be fully zeroed on the next pass.

So while technically true that TRIM is not a deletion protocol directly, it results in the deletion of data on the next garbage collection pass which is normally milliseconds after you delete a file.

3

sauprankul t1_iy4j8jr wrote

Wait, are you saying that garbage collection zeros deleted blocks?

1

LlamadeusGame t1_iy4k8d6 wrote

As far as I understand, yes. There is conflicting documentation out there, and I'm not an engineer so take this with a grain of salt.

That being said, in order to write new data to a block it first has to be zeroed and then written. The idea behind trim and GC is for the block to already be zeroed before you'd want to write to it, therefore improving the perceived response of the drive. There are of course other purposes behind the operation, but it makes sense that if you need to zero an entire block BEFORE you can write to it, you'd want to zero it preemptively and not immediately before a write.

Higher in this comment chain is an article from crucial who describes trim & GC working exactly in this way if you'd like some reading on the subject.

2