You pretty being sure of that and not understanding the relevance of the reply, makes me very sure that you are the one without a clue. And you sound like a bit of dick on top. I wish you luck in your future endeavours.
Oh, but I do. Please note that I do not specify what variety of luck I am wishing.
> I really don't need your wishes.
You have them anyway. Enjoy.
> But you really excel at being butthurt
My butt is just fine, thanks. I can send a picture as proof if you are really interested.
> Your inability to notice T.R.I.M.
I know about TRIM. I also know it is irrelevant to the performance issue being discussed. TRIM works over the SSD's native block size which is much larger (usually at least 512KB, could be several MB depending on controller and memory layout) than the filesystem's granularity (usually 4K or of similar order). The OS can ask the drive to TRIM smaller parts all it likes, and nothing will happen because to do that the drive would need to relocate the rest of the block causing a full (ssd native sized) block READ+WRITE.
The issue defragmenting in this instance deals with is how filesystem blocks are arranged within the SSD's blocks: keeping those close by in the same block. The order within the block won't matter, but if due to fragmentation the filesystem blocks of a file are spread through many SSD blocks then reading that file will take longer than if they aren't. TRIM does nothing here, TRIM is not aware of the filesystem layout.
> "bit of a dick"
Sorry, am I underestimating? Should that have been a lot of a dick?
I also knew about reserve capacity. And I know, that like TRIM, it has no direct effect on the performance issue being discussed here (cause by file blocks being spread around larger blocks in the SSD's granularity).
I have not back peddled at all. You are the one bringing up new concepts randomly.
> Keep us updated.
“us” is just me and you, your first childish post has long since been flagged so no one else will be seeing this.
