David Kanter (dkanter@realworldtech.com) on 1/24/11 wrote:
---------------------------
>anon (anon@anon.com) on 1/22/11 wrote:
>---------------------------
>>Rob Thorpe (rthorpe@robertthorpeconsulting.com) on 1/22/11 wrote:
>>---------------------------
>>>Linus Torvalds (torvalds@linux-foundation.org) on 1/20/11 wrote:
>>>---------------------------
>>>>Megol (golem960@gmail.com) on 1/20/11 wrote:
>>>>>
>>>>>Linus "ass***e" Torvalds not understanding something and insulting everyone that
>>>>>have a clue. How come I'm not surprised?
>>>>
>>>>Why do you think I'm here? If I wanted to have an intelligent
>>>>discussion with people I care about, I'd be writing emails
>>>>to kernel people. "Arguing vigorously" is my hobby.
>>>
>>>To put things differently, for the purposes of RWT forums you're a troll.
>>>
>>>What I can't understand is why Dean and David have let your behaviour in this thread
>>>go and not thrown it into the unmoderated forum.
>>>
>>>FWIW I don't know or care much about TRIM. But, I'm reminded of a line from "The Big Lebowski"...
>>>
>>>"You're not wrong Walter. You're just an asshole."
>>
>>Pretty sure everybody else was wrong and an asshole. Linus had actual numbers and
>>real reasons. Everyone continued to bait him and handwave and assert how they were
>>right and he was wrong with nothing to actaully back it up.
>
>As a number of people pointed out, the numbers were intriguing and surprising...but
>it's hard to judge them given the lack of test conditions.
>
>>Let's be clear here. People were not saying "Oh well I would have thought trim
>>should be fast because X, so given the actual numbers and experiences you have provided, I wonder if Y".
>>
>>People were saying "No I'm right and you're wrong, trim is fast and obviously always
>>right to always do it. I have no numbers and nothing but vague handwaving about
>>what I believe an FTL should do, but in any case you are definitely wrong.".
>
>Actually, it seems to me that the overall response was: "Yes, it appears that some
>drives with TRIM have a really really crappy implementation that causes problems,
>that doesn't necessarily mean that the idea sucks though."

Nobody says the idea sucks. Even the implementation it is agreed that it is a no-brainer to use in offline mode, regardless of the drive implementation.

But the assertion that it is trivial to implement in FTL is absolutely wrong. To actually go through the thought exercise of why, then you need to build up the entire log structured block device system to be used.

It is hardly likely to be a simple forward map in fast RAM which requires only a few instructions to switch, and is all magically backed by supercaps etc etc.

If you try to make the argument that it is simple, you can't just handwave away all these details and assert that you are right and therefore everyone else is wrong.


>TRIM is a pretty complex subject - it doesn't work real well in RAID and many enterprise
>systems will probably disable it, in favor of techniques that scale over multiple SSDs.
>
>As was also pointed out, it many respects, a DRAM or SRAM write combining buffer
>is a vastly better solution - however many vendors avoid that for cost reasons.
>Some for data safety reasons. It seems to me that this is an area likely to see improvement...but hard to say.

No this wasn't pointed out, it was handwaved. It's not that simple, even if you have caps to write out several megs of data (as I pointed out, the full mapping could be well over a gigabyte in size).

>The point that using TRIM as a crutch for a cheap/crappy SSD seems pretty valid.
>I think a more interesting point is whether a good TRIM implementation can improve
>performance/longevity for a properly designed and suitably robust SSD.
>
>Another related question is whether changes in the FS would help (or not).

The point is that for a _lot_ of usages, trim is pure overhead regardless of how well it is implemented, because the filesystem is likely to use logical blocks again. So the question of how well it can be implemented does not even come to figure.

Given that, it hardly seems like something that an FTL should optimize for (at least, if it comes at the expense of normal re-write reallocation, or requirement of a lot of battery backed dram).