Linus Torvalds (torvalds@linux-foundation.org) on 1/21/11 wrote:
---------------------------
>Ricardo B (ricardo.b@xxxxx.xx) on 1/21/11 wrote:
>>
>>Can *anyone* point out those mythical SSDs
>>
>>- for which TRIM reduces performance, either in the short or long term.
>
>Umm. It's more like the reverse.
>
>The _common_ case is that trim reduces performance, because
>it makes file delete slower.
>
>In fact, I can pretty much guarantee you that it does that
>on just about every ssd that supports trim out there.
>
>And on some systems, trim just makes them unusable, because
>the ssd is so bad at it.
>
>Of course, part of it is the actual trim patterns, but
>see for example
>
>http://people.redhat.com/jmoyer/discard/ext4_batched_discard/ext4_discard.html
>
>just to see some numbers, since people seem to be in denial.

Well, well, well - what do we have here??? Some canned benchmarks showing the imperfection of some algorithms in EXT4? Blah - nonsense - EXT4 is perfect and almost godlike, everybody knows that.

So, instead, the only option left (since EXT4 is the materialization of perfection, maybe even the will of the God himself (or herself)) is that the performance issue is caused by TRIM! That is logical. That's right - the cause cannot be the *misuse* of TRIM by *EXT4* - the divine truth for all folks to see is the evil nature of TRIM, and of TRIM alone.

Anybody who sees something different here than "TRIM is evil" is committing blasphemy. We should burn such people!!!
We have to burn such people!!!

>Yes, those "1000%" things are real. See how the "good"
>devices only slow down by 15-20%, while the bad device gets
>ten times slower when the filesystem sends discards for
>blocks as it deletes them.
>
>Yes, yes, so people are trying to come up with better
>ways, where you discard in batches, and where you just
>discard entirely off-line. As mentioned, my personal
>opinion is that on-line trim is just stupid, and doing
>it offline (when the system is quieter - so not necessarily
>_totally_ offline, but basically not during real ops)
>is the only sane approach.
>
>But dammit, can you guys shut the f*ck up already?

Good! Another "intellectual diamond" of yours. There are so many all over this forum. Keep up the good work. So ... why don't you f*ck your daughter while your wife is watching?

>Admit
>that you were wrong, and trim isn't fast, and isn't a
>simple thing.

Even if all people would admit they were wrong, it does *not* mean that you were right.

>Because IO patterns matter, and without ESP
>you can never know when it's a good idea to TRIM.
>
>99% of the time, you're probably much better just reusing
>the block and letting the normal write activity be
>the "trim and overwrite".

Yes, in *certain* cases the strategy of letting the normal write activity do the TRIM works perfectly.

>I'm done arguing. Come back when you have re-acquainted
>yourself with reality. As it is, I'm just seeing a lot of
>"TRIM should be fast" noise, with no f*cking clue.

"No f*cking clue"? Many of your contributions here are demonstrating that you are suffering from some kind of mental illness. Are you sure you are not writing your posts from a mental institution?

>Linus

Yeah, the guy who has "f*cking clues" - while anybody who disputes his Godlike ideas has no "f*cking clue".