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."
>
>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.

SSDs require trim to maximise lifespan. sigh.

>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.

No, it doesnt do the same thing!

>Some for data safety reasons. It seems to me that this is an area likely to see improvement...but hard to say.
>
>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.

I find it interesting that people in this thread dont actually seem to understand TRIM, and yet when I explained its requirement, there was a total of zero responses - did I explain it that poorly?

>
>Another related question is whether changes in the FS would help (or not).

No, they would not.

TRIM is required for disk reorganisation to allow optimal write leveling, and can also have possible performance benefits, but disk lifespan is its reason for existing!

It is simple.

Without TRIM, a disk must assume any sector ever written to still contains valid data - it CANNOT assume otherwise (unless the FS is going to be implemented in the controller..).
Also, repeat written blocks MUST be moved around, that is the whole point of write leveling..
So therefore, as soon as all of the disk has been written to at least once (and this is not at all uncommon!) the controller must assume it must RELOCATE blocks, not overwrite them, as it migrated data arounf for write leveling.
It also cannot pre-erase data, as it does not know that it is no longer used.

So in that case write leveling becomes horrific, often causing multiple read/erase/write commands PER WRITE to do write balancing. Erase is long and slow..

Now, you can design a FS to remember its recently used blocks and reuse them, which helps with free space consumption from the devices point of view - this works if you never get up to high usage.

Or, you can use TRIM.

Now, what Linus argues against is how TRIM in used by the OS! that is not a problem of TRIM (although does point at perhaps poor implementations), it is a problem of the OS. As he says there is little reason to TRIM in realtime. Periodic or resource change based TRIM is very sensible.
Unfortunately he seems to feel that this brush should paint TRIM itself.

Dont blame a required technology for poor use (or even perhaps poor implementation).

As others have said a good TRIM implementation (perhaps with suitable buffering, etc) should be able to achieve realtime TRIM, but that is beside the point.