Pretty sure trim is mainly an ssd thing

pretty sure trim is mainly an ssd thing, a regular hdd doesn’t have to prep an area for write, while an ssd does, thus when doing a trim areas containing old data is zeroed out so that doesn’t have to be done when a write is incoming.

hdd’s just rewrite directly, doesn’t matter if it was empty or contained data in advance…

or atleast thats my understanding of it… so in that case trim in the sense of what ssd’s does can never be a thing for hdd’s unless if its some sort of hybrid…

ofc SMR aka shingled are sort of a weird technology which writes multiple lines of data on the platter overlapping… i suppose on an empty SMR drive its possible to do something similar to the difference between SLC,MLC,TLC,QLC and so on an so forth.

ofc that just offsets the rewrites for later and thus creates more workload but improves burst speeds, however for something like a storagenode it’s not really going to help…

a continuous load especially if at a level near max performance will generally make everything slower, even trim on an ssd would create extra latency, if the ssd wasn’t practically idle most of the time…

haven’t read the link, but yeah i’m sure there are lots of tricks to make SMR perform better, but trim doesn’t really improve performance, it does workloads in advance and thus can react faster during burst loads… so it would inherently always come at a overall performance loss…

i do use trim myself on all my ssd’s, and it’s magnificent, gives me about 30% better performance, pretty sure there is some sort of performance penalty for that, but not sure how great it is on ssd’s.

but for hdd’s i don’t see it as being very viable, aside from burst writes on SMR.
so maybe… but i doubt it…

Facts are better than guessing :wink:


its a buzz word, if you read the actual entry you would realize it doesn’t trim anything… it reduces seek trashing, so sure it helps… but it’s nothing like what trim means for a ssd directory branch or database structure being pruned, which is why it’s called trim in the first place…

i reject your reality and substitute my own.

1 Like

Trim as become a generic term to “I will let the storage subsystem this bit is not longer used, deal with it the way you want” Even on SAN or virtualisation it is used for thin provisioning.

And i get the reference, love it :slight_smile:



@JDA : Since the node already pre-allocates, maybe you can update this suggestion to pre-allocate using final piece size instead?

1 Like

I updated the title and description in that way

1 Like

stuff is confusing enough to begin with, keeping some sense in the naming of things helps minimizing confusion.

which i’m sure is also their argument for naming it trim on hdd’s to begin with… lol the irony is not lost on me there…

The argument is because it performs exactly the same job. The only difference being how the drive internally handles it. But that can even differ for different SSD’s.

In both cases:

  • The OS informs the drives of blocks no longer in use.
  • The reason the drive wants to know is because it can prevent having to do a read operation before a write, to preserve other data in the block or in adjacent tracks.
  • The drive performs internal maintenance and garbage collection to optimize storage performance based on this knowledge.

Since the SSD itself is usually not aware of file systems or directory structures, it can’t possibly do this:

That is just not what trim does. At least not the ATA TRIM or iSCSI UNMAP commands we are talking about here. The term trim is used for different things in other contexts though.

But this topic isn’t about trim, so I’ll stop talking about this now. (Edit: it is now! Thanks for the move @Alexey!)


Modern large so called pmr drives are also smr to some extent and smr drives are also partly “pmr” They can all benefit by implementing trim