Linus Torvalds (torvalds@linux-foundation.org) on 1/19/11 wrote:
---------------------------
>You have bought the whole TRIM story hook, line and sinker.
>
You have bought the whole free() story hook, line and sinker.

>It's bogus. There is currently absolutely no reason to
>support TRIM, not on SSD's, not on anything else. The whole
>feature is totally broken.
>
It's bogus. There is currently absolutely no reason to support free(), not on OS's, not on anything else. The whole feature is totally broken.

Does that sound kinda stupid? Because it basically what you said.


>The fact is, any SSD worth anything should work perfectly
>fine without trim, and if you need trim to get it back to
>good performance, you should just ditch the SSD entirely.
>
TRIM serves effectively the same purpose and function as free/dealloc does in programming. I think you and greatly misunderstanding the reasons for it.


>The whole "SSD's need TRIM" support was a bedtime story for
>gullible morons. The same morons who also bought the "SSD's
>need big IO and natural alignment" story that came out a
>couple of years before that.
>
Actually, TRIM serves a useful function in storage and natural alignment is always a good thing. Are now suggesting that advfmt drives shouldn't use natural alignment as well?


>The fact is, SSD's had seriously buggy garbage collection.
>TRIM was a workaround for an SSD firmware bug, nothing
>less, and most definitely nothing more. Yes, yes, it can
>make a difference, but it's not at all the magical fairy
>dust that people have claimed it was. The real solution
>was always to just fix the performance bugs in the bad GC
>that SSD's did.
>
TRIM was NOT a workaround for buggy garbage collection. There are very good reason why TRIM has been included in all major storage protocols for a while.

>More specifically, TRIM is also incredibly buggy, and slow
>on certain drives.
>
Then don't buy those drives.


> So doing TRIM in the OS is dangerous,
>and is likely to result in totally unacceptable performance
>if it's used on-line (ie when removing files). And you also
>raise your risk for hitting those drive-bricking bugs, so
>it's doubly dangerous.
>
Really now, considering there are millions to tens of millions of SSDs using TRIM...

>In fact, even when it's not really slow (and when it's not
>buggy), it still makes a normal file deletion much more
>expensive, since normally you'd just throw the blocks away
>without doing any IO at all. Doing even a fast TRIM is thus
>infinitely more expensive.
>
Actually, TRIM makes things generally faster be it on SSDs or whole storage systems. TRIM is merely a hint. The devices are free to consume it or not.


>End result: nobody sane enables TRIM by default, and it's
>almost inevitably a total marketing point. And in reality,
>you'd want it to be an off-line feature, ie something akin
>to doing a defrag event, rather than something you do as
>part of a normal filesystem operation.
>
Most sane people enable TRIM by default because it results in faster operation. It is not a total marketing point.


>Maybe the above will change eventually, but right now
>TRIM is totally oversold, and totally pointless. Just don't
>even bother with it. Do your SSD comparisons after you've
>done lots of random writes, and expect that in real life
>the time when an SSD can optimize its GC i when you do nice
>large file writes. Not when you TRIM things.
>
This contradicts all published data.

>And even _if_ TRIM becomes relevant (and I doubt it ever
>really will - good GC makes it largely pointless), it just
>won't be a huge deal.
>
TRIM accelerates GC and makes the GC less heavy weight.


>Repeat after me: if your disk manufacturer talks about
>how you need to TRIM the drive, they're cutting some corners
>that you do NOT want to be cut. Buy another drive.
>

So which SSDs would you recommend?