On Feb 8, 2014, at 3:04 PM, Michael Cronenworth <mike(a)cchtml.com> wrote:
On 02/07/2014 06:54 PM, Chris Murphy wrote:
> And here is a recent thread, just under one year old….
>
>
https://lkml.org/lkml/2013/2/23/107
>
> Anyway, the fs developers have been speaking about it quite a bit and for a long
time.
I guess I could have Google'd for this, but after reading over a few of these links
they don't produce any quantitative evidence that TRIM (in its current state) causes a
significant problem.
So what you really wanted was quantitative evidence, rather than reading what fs
developers had to say about using trim. In that very thread, the O.P.s problem was solved
by removing the discard mount option. I don't understand how that's not
qualitative evidence, or how the described problem wasn't significant.
There are all sorts of threads where users are having brief system hangs, to outright
sluggishness, and they go away when trim is disabled.
And even aside from what you might consider minor performance hiccups, how about it being
totally disqualifying for use in raid of any sort if trimmed sectors return
non-deterministic results when subsequently read?
I see theoretical discussions that TRIM, being non-queued, can be
detrimental. However, real-life performance tests show TRIM use to be insignificant.
It clearly depends a lot on the SSD used and workload involved. That sata-io have
published SATA Rev.3.1 with a queued trim command expressly to address the problems that
occur when mixing queued and non-queued commands in typical usage seems fairly significant
to me. The storage manufacturers agree with each other almost as a last resort, and rarely
so quickly.
Windows 7 and higher uses TRIM in a "discard"-like manner and it is
automatically enabled. I do not hear of Windows users complaining about poor performance
or blog posts recommending it be disabled (in fact Google will show the opposite).
I supposed you've Googled this with the same thoroughness as before?
As it turns out there's quite a trove of results for people having short freezes in
Windows attributed to SSDs. Once they learn how to disable trim for the drive, their
problems go away. It's also misleading to say that Windows always enables trim,
because at least if the drive isn't also supporting drat and dzat it won't enable
it. And not all drives do support some form of deterministic read after trim.
I'd characterize the problem as a minority case, but it seems in the vicinity of a
significant minority, if you have certain cheap/crap SSDs on the market and a workload
that triggers the problem. But it's not like it's rare, and it's not like
it's a figment of people's imagination. Like I mentioned before, Apple doesn't
enable it on any 3rd party drives by default, and it's not because they can't.
It's likely because of the way they're constantly creating and deleting small
files (mostly application preferences and system configuration files) in order to get
something like what COW file system would get them for free, they create a new file, and
delete the old on rather than overwriting it. When I had trim enabled in OS X with my none
crappy or cheap Samsung 830, I noticed an occasional 3-5 second freeze where the system
wasn't responsible. After disabling trim the problem went away. With or without the
discard option with Btrfs on the same system, I've thus far experienced no difference
in behavior, but then Btrfs is COW and likely has substantially better delayed allocation
and batch trimming than what Apple is doing.
But yes that's all rather anecdotal than either qualitative or quantitative.
Chris Murphy