anon (anon@anon.com) on 1/19/11 wrote:
---------------------------
>The reality is that you do that, you have trim submission, then command overhead,
>and then FTL overhead and potentially even some update to the media on a trim. On
>the next IO, your filesystem's block allocator dutifully reuses the same exact block
>and all that trim work is pure overhead.


Uh, from what you say here it sounds like you don't understand what TRIM does or how SSDs work. I assume this is just a poor choice of wording, but it will confuse some people.

The filesystem cannot "dutifully reuses the same exact block". It is writing to what it thinks of as 'sector x' from the OS point of view, but that number is a lie. The SSD controller will take the 'sector x' write from the OS and translate it to whatever sector number it wants on the SSD itself. The SSD CANNOT re-use the old sector until it has been erased. You can write over old data on a hard disk, but you cannot do so on an SSD. It must be erased first. And in any case, an SSD with that implements any form of wear levelling would not allow the same sector (on the SSD itself) to be immediately re-used after erasure unless the drive is completely full.

So the TRIM is not a waste at all, the only overhead is a tiny command sent to the SSD. If the SSD does a whole lot immediately in response to that tiny command, then it is acting stupidly. There is nothing in the TRIM spec that says it must.

I must admit I'm kind of confused what Linus is on about in this thread, but hopefully he'll chime in and clarify his comments, rather than just calling TRIM "broken". Calling it broken and saying not to use it conveys no useful information, and the fact he's replied several times to this thread already with lengthy posts kinda demonstrates that any savings in time he hoped to accomplish by saying "its broken, don't use it" versus giving a more detailed explanation of exactly how it is broken isn't really working out for him :)

It sounds like he is saying that TRIM on these broken SSDs immediately erases the sector in question, which I agree would be quite stupid. That would mean some SSDs are immediately issuing the erase to the block that this sector is a part of, which in the best case means that free blocks are being erased right away instead of marking it as work to be done later. And worst case would mean the SSD is moving other data a partially free block to another free block on the SSD. Both would reduce performance unnecessarily, the latter would also reduce the SSD's lifespan!

The point of TRIM should not be to tell the SSD "immediately erase this area of the SSD", but to tell the SSD "put this area on the free list". Once there is a contiguous unit large enough to form an eraseable unit (a block) then the SSD can do the erase at any time. Presumably it would only do so when it is idle, or in a state of lower than normal I/O (i.e., if it is an enterprise drive which may never be totally idle)

Perhaps what Linus means when he talks about broken implementations of TRIM, are implementations where the drive is stupid enough to attempt to immediately erase whatever areas of the SSD that are trimmed, or which do internal cleanups not when the drive is less busy or idle, but whenever a contiguous free block is formed - which could often be during periods of high I/O, like when you are doing a big 'mv' or the Windows equivalent, and you are deleting files (causing a TRIM) intermixed with writing files (when you don't want the erases actually happening, unless the drive is so full you have no choice in the matter)

Since implementing TRIM is new and there are a variety of controllers, each with their own software, I have no trouble believing that some SSDs are broken in this manner. But I think in a technical form like RWT people should back up their statements with more than "its broken". Particular if there has been some actual testing done to determine the exact nature of the brokenness. I suspect there has in this case - if not by Linus personally, by someone else whom he trusts. I'm not saying I don't trust Linus enough to believe him, just that I think it'd be nice if we were provided the information, or a link to it...

Even MSDOS correctly manages a free list, so that when you delete a file it marks the blocks as unused, and can be re-used. I don't really see why anyone should worry too much about an SSD getting this wrong, it should be something that would turn up pretty quickly in testing. To be honest, this worries me way less than wear-levelling algorithms, as that's doing something a lot more complicated than managing a free list. If Linus is trusting SSDs with wear levelling enabled, I fail to see why he should not also trust one with TRIM enabled. Maybe TRIM reduces performance and perhaps lifespan as well, and that would be a valid reason to leave it off, but worrying about bugs in its implementation while feeling comfortable with wear levelling makes no sense to me.